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

For Apache httpd with "HttpProtocolOptions strict" 
(which is the default and we recommend for obvious reasons), 
requests with a fragment give a 400 response.

Mode "Unsafe" would allow this. An exception is mod_dav which
seems to reject fragments unconditionally.

Hope this helps,
Stefan

See: <https://httpd.apache.org/docs/2.4/en/mod/core.html#httpprotocoloptions>

> Am 27.07.2023 um 11:05 schrieb Willy Tarreau <w@1wt.eu>:
> 
> 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...
> 
> We could also consider that we continue to accept it and just trim it
> from the functions that extract it for internal processing, but that
> would mean we'd continue to pass it to the server, which is contrary to
> the rules imposed to a client (even though we're a gateway here, but
> still we try hard to comply as much as possible and sometimes to repair
> damaged protocol elements if needed and permitted).
> 
> We could also completely trim this one when receiving the request, and
> probably match more closely what the few servers I've tested seem to do,
> but given that we're not supposed to receive them, I'm wondering if we're
> not hiding the dust under the carpet. It will also mean that they wouldn't
> appear in logs anymore, preventing from observing them.
> 
> Thus I'd like to collect some opinions here from other implementers.
> Are there any who reject requests containing fragments in the URI ? If
> not, are there any good reasons for not doing so (e.g. clients caught
> sending them from time to time in the past and situation nor re-evaluated
> since; lack of clarity in older versions of the spec, etc) ?
> 
> Without strong support for rejecting these as invalid, I'm probably going
> to silently fix these requests by trimming the fragment like others seem
> to do, but I really do not like doing such things that hide interoperability
> issues without a good reason first. We already have normalization rules
> in place to either reject or trim, but they're currently opt-in so we
> can't count on that to collect more feedback.
> 
> Thanks in advance,
> Willy
>

Received on Thursday, 27 July 2023 09:56:00 UTC