A bit confused...

[Francis Daly]

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
-- 
Francis Daly        francis at daoine.org