On Fri, Jun 12, 2015 at 07:38:19PM +1200, Steve H. wrote:
On 12/06/15 18:59, Francis D. wrote:
On Fri, Jun 12, 2015 at 01:50:15PM +1200, steve wrote:
Hi there,
$ curl -I right.bike FS.png
HTTP/1.1 200 OK
$ curl -I right.bike HT.png
HTTP/1.1 400 Bad Request
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.
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.
A filename with spaces isn’t a problem.
A http request (url) with spaces is a problem.
Create different files called “50%good”, “50%bad”, “%”, “%25”, and
“wtf?”, and try to access them as if their filenames can be used
directly in http requests. You’ll see different responses – errors
or not-the-file-you-wanted – all of which are understandable when you
accept that a filename cannot be used directly in a url.
You must always url-encode a filename when creating a url.
If the filename is restricted to alnum-dot-underscore, then “url-encode”
is the identity transform. For the full details, RTFRFC.
No matter what, one passes and one fails. It’s not repeatable
behaviour.
space-H fails, space-anything-else passes. That looks repeatable to me
#196 (Inconsistent behavior on uri's with unencoded spaces followed by H) – nginx has some background. The short
version is that all should fail, and all did fail, but to be kind to
broken clients, nginx was changed to let most pass. That was a
convenient
change, but does lead to this confusion.
(I think that a subsequent change meant that the response is in HTTP/1
format, rather than the HTTP/0.9 that it originally should have been.
That
one was a good change.)
So don’t succeed riding the bicycle most of the time is
the way I see it.
urlpart=urlescape($filename)
Then always use $urlpart instead of $filename when you write the link,
and it will always work.
(This is a http thing, not an nginx thing. Other web servers will have
their own error-handling and error-correction, which will probably not
be identical to nginx’s.)
The first time I’ve ever disagreed with you Francis!
Not a problem. I think the only difference of opinion is whether, given
a broken request, most should pass or none should pass. And both
opinions
are reasonable.
I think that the Right Answer is for there to be Yet Another Option so
that one can configure “reject_malformed_http1_requests” to make all
requests containing space (and possibly all http/0.9 requests, as an
implementation-convenience consequence) fail immediately.
Or just revert the patch linked from the trac message and hear the
users complain.
But since I won’t be writing any of the code, my vote counts for little.
Cheers,
f
Francis D. [email protected]
