A bit confused...

[Steve Holdoway]

Hi,

On 12/06/15 18:59, Francis Daly wrote:
> On Fri, Jun 12, 2015 at 01:50:15PM +1200, steve wrote:
>
> Hi there,
>
>> I'm tryiong to make some sense out of this and am left a bit cold!
>> What could cause this:
> Both requests are invalid - "space" may not appear in a url. Encode it
> as %20 and things will work.
>
> nginx happens to try one form of "dwim" error recovery when the character
> after the invalid space(s) is not "H", and does not try it when the character
> is "H".
>
>> $ curl -I http://backend.right.bike/images/models/Lapierre/Overvolt\ FS.png
>> HTTP/1.1 200 OK
>> $ curl -I http://backend.right.bike/images/models/Lapierre/Overvolt\ HT.png
>> HTTP/1.1 400 Bad Request
>> The second one shows no entry at all in the access log but I can't
>> find any reason why they're processed differently at all.
>>
>> Suggestions please!
> I presume that the nginx request-line parser stops at the whitespace which
> says "end of url, what follows is the HTTP version", sees that it does
> not start with "H", and decides "perhaps this is an invalid url; I'll
> carry on parsing and maybe I can helpfully handle this broken request";
> or sees that it does start with "H" and decides "clearly this was the end
> of the url, I shall now identify the HTTP request version; oh, it's broken,
> error 400".
>
> You could argue that nginx could try an extra level of dwimmery to try
> to drag something useful out of the second broken request; or you could
> argue that it should fail the first broken request as well.
>
> Or you could accept that the client has broken the protocol, and the
> server is mostly free to do what it likes in response.
>
> I suspect that "fail the first broken request" won't happen, as a
> practical QoI matter; and "try to accept the second broken request"
> might happen if someone who cares can provide a low-impact patch --
> it's easy for me to say "it's a Simple Matter of Programming", because
> I don't intend to write the patch ;-)
>
> But "don't make invalid requests" is the way to see the bicycle.
>
> 	f
I have 750 image files, many of them have spaces in their names. The 
example I showed, and the 30 that deliver a 400 bad request status *all* 
contain a ' H' in the file name. ' h', ' G' and most things similar 
return a 200 status.

No matter what, one passes and one fails. It's not repeatable behaviour. 
So don't succeed riding the bicycle most of the time is the way I see it.

The first time I've ever disagreed with you Francis!

Steve