Ambiguity about how to deal with received fragments in URI

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:05:14 UTC