A bit confused...

[Francis Daly]

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:

Hi there,

> >>$ 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
> behaviour.

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.

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