A bit confused...
francis at daoine.org
Fri Jun 12 08:35:19 UTC 2015
On Fri, Jun 12, 2015 at 07:38:19PM +1200, Steve Holdoway wrote:
> On 12/06/15 18:59, Francis Daly wrote:
> >On Fri, Jun 12, 2015 at 01:50:15PM +1200, steve wrote:
> >>$ 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
> >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
space-H fails, space-anything-else passes. That looks repeatable to me :-)
http://trac.nginx.org/nginx/ticket/196 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.
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
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
But since I won't be writing any of the code, my vote counts for little.
Francis Daly francis at daoine.org
More information about the nginx