[Mono-aspnet-list] nginx + multiple fastcgi-mono-server4 instance => WebResource.axd 404 error
ovidiudeac at gmail.com
Wed Jan 2 14:09:07 UTC 2013
Thanks for the answer.
So the short version is that if I want to have multiple instances of the
application and do load balancing then I must drop mono and use .NET
Is there any other possibility to achieve load balancing/high availability
On Wed, Jan 2, 2013 at 3:20 PM, Kornél Pál <kornelpal at gmail.com> wrote:
> Based on the source code of Mono's
> System.Web.Handlers.AssemblyResourceLoader I think that the implementation
> is flawed.
> I am going to describe the problem, but I think that you should file a bug
> Although it is using a hashing algorithm that always results in the same
> hash for the same script resource, hashes are not generated and stored in
> the dictionaries unless a link is generated, thus a resource is not
> available until a link to it was generated by the same AppDomain before.
> As such even AppDomain restarts can trigger the problem, although a simple
> refresh on the page fixes it by generating hashes for the web resources
> that subsequently can be retrieved from the server, provided that there is
> only one AppDomain (one process, one server) serving the requests.
> As I see at least the assembly name should be included in the query
> string, resource hashes can be regenerated based on WebResourceAttributes
> of the assembly.
> To prevent loading arbitrary assemblies, the assembly name should be
> encrypted using the machine key and also should be signed using HMAC to
> avoid padding oracle vulnerability similar to CVE-2010-3332 that the MS
> implementation had (encrypted view state, forms authentication cookie, and
> WebResource.axd were all affected).
> On 1/2/2013 12:34 PM, Ovidiu Deac wrote:
>> I'm running nginx which does load balancing over several instances of
>> Apparently when a webresource link is handled by a different
>> fastcgi-mono-server than the one which originally produced the link it
>> returns a 404 error.
>> I have set a persistent machinekey as recommended for webfarms but the
>> problem still remains.
>> Any idea what else could be wrong?
>> If it makes any difference: the application is written with
>> F#/WebSharper and we disabled the session state and the forms
>> Mono-aspnet-list mailing list
>> Mono-aspnet-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-aspnet-list