spaces in URI

[Peter Portante]

Hi Igor,

This is working great. Thank you!

Should we be prepared to maintain this as a patch on the 0.8 stream, or
would some variation of this fix be folded into 0.8 (via some config setting
or as the new behavior)?

And while we are at it, how stable is 0.8? I thought I had seen some
discussion of 0.8 being marked "stable" soon. Just curious.

Thanks,

-peter


On 6/11/10 4:09 AM, "Igor Sysoev" <igor at sysoev.ru> wrote:

> On Fri, Jun 11, 2010 at 02:54:35AM -0400, Peter Portante wrote:
> 
>> Hi Folks,
>> 
>> We are running into a small problem with bad HTTP clients.
>> 
>> We have sold a bunch of hardware with embedded HTTP clients which don't
>> URL-encode the parameter values. For example:
>> 
>>   GET /a/r?did=X234 567 Y HTTP/1.1
>> 
>> We were using a pair of Apache servers behind a hardware load-balancer and
>> switched our environment to front those Apache servers with a pair of Nginx
>> servers. We actually use those Nginx servers for a number of other web sites
>> we serve.
>> 
>> When we made this switch, these particular clients stopped working. Nginx is
>> responding immediately after receiving the "GET" line above with "400 Bad
>> Request". This *is* valid behavior on Nginx's part, as according to our
>> understanding of the HTTP protocol, no spaces are allowed in the request
>> URI.
>> 
>> Apache is apparently rather forgiving on this front. Is there some setting
>> or configuration parameter in Nginx that would make it more forgiving of
>> these spaces in the request URI?
>> 
>> If there is not, would it be difficult for us to modify Nginx to make it
>> more forgiving? If so, any pointers as to where to start?
>> 
>> Our other options we can think of are:
>> 
>> 1. route HTTP traffic from these clients to Apache servers
>> 2. leave them dead in the water until customers complain so we can tell them
>>    to upgrade their firmware for the fix
>> 
>> Thanks for any help or pointers you can offer.
> 
> Try the attached patch against 0.8.40.
>