On 13/07/12 22:39, Maxim Dounin wrote:
> Hello!
>
>> whereby we had a config snippet which looked like:
>>
>> error_page 400 @fallback
>
> Don't do that? (c)

Yeah, we stopped doing that pretty quickly once we realised the trouble it was causing.

> The problem with 400 errors is more or less trivial and the above
> link explains it in details. There is no need to debug anything
> here, it's mostly about writing code to handle it. (Or probably
> about writing code to make the above config invalid and/or provide
> a warning.)

Yes, any of these options sounds good to me.

> Note well that handling of 400 errors isn't really good idea even
> with normal uri of an error page, not only with named locations.
> As 400 (Bad request) means bad request and you can't really trust
> anything got from a client. Unless you really understand what are
> you doing and possible implications it's much better idea to let
> nginx return builtin error page.

Agreed, although it was a little surprising that nginx was segfaulting as a result
of poor configuration choices.

I'm surprised that nginx even allows 400's to be proxied to be honest - I can't
really think of a situation where you'd want to do that, unless you were relying
on the content of the 400 response for your application.

I'll try building without optimisation and see if I can trace the source of the
segfault anyway, if only to satisfy my own curiosity.

--
Russell Howe
rhowe@moonfruit.com

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx