segfault in nginx 1.2.0 and 1.2.2 when serving 400 error pages via a reverse proxied host

[Russell Howe]

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 at moonfruit.com