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

Hi,

On Thu, Jul 27, 2023 at 03:54:01PM +0200, Julian Reschke wrote:
> On 27.07.2023 14:17, Sean McArthur wrote:
> > I agree the handling for a server is ambiguous. In hyper, we've just
> > ignored including it in `req.uri()`, so user code cannot access it. If
> > it were clarified in the RFC that we should reject with a 400, we could
> > consider making that change.
> > ...
> 
> RFC 9110, Section 4.2.5 says "not allowed". I believe this is sufficient
> reason to respond with 400.

Well, in theory yes, in practice we know it's often much more shaded due
to what exists in field, and that the spec often focuses more on "never
send this again" than "never accept this" :-)

The fact that some well-known implementations already block it by default
is sufficient to convince me to do the same now. In any case we do have
an option to relax request and response parsers, so should anyone really
need it to accommodate a bogus application, it would still be possible.
At least with blocking they'll get a capture of the exact reason for the
error, which would then explain the cause, so I'm totally fine with this.

Many thanks to all those who responded so quickly, I feel safer now with
the stricter approach!

Best regards,
Willy

Received on Thursday, 27 July 2023 16:49:58 UTC