Re: Ambiguity about how to deal with received fragments in URI

On Thu, Jul 27, 2023 at 11:05:07AM +0200, Willy Tarreau wrote:
> Hello,
> 
> An haproxy user rightfully reported that we don't ignore the fragments in
> the URIs we receive. While that's historically true and comes back from
> the old days where any byte from one side would be passed to the other
> side, I'm facing a dilemma about how to best deal with it.
> 
> Indeed, RFC9110 is pretty clear about the fact that URIs do not contain
> the fragment component, and even refers to RFC3986 that omits it for
> scheme-based absolute URIs. But as often, this only concerns senders and
> does not suggest much about how to proceed on the receiver when that rule
> is violated. I could be tempted to say that if a fragment is present, the
> the rule is violated and I should just reject the request as bad with a
> 400. I tried various web servers (among which Apache and NGINX) and all
> silently trim any received fragment, which leaves me with even more doubt
> about the suitability of the 400 here...

Looking at the reverse proxy code I wrote, looks like it rejects
fragments with 400 error that is fatal in HTTP/1.1 (obviously not fatal
in HTTP/2).

Internally, what happens is that it tries to decode the fragment either
as path or query, but because # is not legal in either, that fails,
causing fatal 400 error.

In the logs of one small server, I found ~dozen attempts in last ~3
months. Interestingly, all are path position 1, which means the request
starts with '/#' (what comes after that was not logged, however I guess
it was "/#http").




-Ilari

Received on Thursday, 27 July 2023 13:06:57 UTC