spaces in URI
Peter Portante
peter.a.portante at gmail.com
Sat Jun 12 00:53:28 MSD 2010
Great. Thanks Igor, we are using it. :) -peter
On 6/11/10 4:35 PM, "Igor Sysoev" <igor at sysoev.ru> wrote:
> On Fri, Jun 11, 2010 at 04:07:10PM -0400, Peter Portante wrote:
>
>> 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.
>
> Here is a new patch that encodes these spaces as %20 while talking
> to a proxied backend. I'm going to commit the patch in next 0.8.41.
> 0.8 is stable, use it.
>
>> 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.
>>>
>>
More information about the nginx
mailing list