Re: #904: Content on GET requirement strength

On Fri, Jul 16, 2021 at 06:41:37PM +0200, Julian Reschke wrote:
> Am 16.07.2021 um 18:11 schrieb Carsten Bormann:
> > On 2021-07-16, at 16:33, Mike Bishop <mbishop@evequefou.be> wrote:
> > > 
> > > prior arrangement with all parties -- and it's otherwise prohibited.
> > 
> > Why is this one different from other places where the standard is making clear mandates and there is still behavior out there that violates those?
> > Are we downgrading all MUSTs to SHOULDs as soon as we see deviating behavior between consenting implementations in the wild?
> > ...
> 
> Adding history:
> 
> In RFC 2616, the spec had no normative requirement not to send GET
> request bodies.
> 
> RFC 7230 added a statement about the payload having no defined syntax,
> still no normative requirement.
> 
> The current draft, after two LCs, now says:
> 
> "A client SHOULD NOT generate content in a GET request. Content received
> in a GET request has no defined semantics, cannot alter the meaning or
> target of the request, and might lead some implementations to reject the
> request and close the connection because of its potential as a request
> smuggling attack (Section 11.2 of [Messaging])."
> 
> This discussion is about either adding more prose to the SHOULD NOT, or
> further *upgrading* it to a MUST NOT.

I'd add that the algorithm described to determine the presence of a
message body and its length covers all use case, and that I would find
it particularly dangerous to consider that absolutely all methods including
unknown ones use the standard algorithm *except* GET.

I find the "SHOULD NOT" well balanced to discourage attempting to use that
over unknown infrastructure components without suddenly declaring all
compatible implementations non-compliant. As proposed there, adding an
"unless negotiated by other means" or something along this would be nice
though.

Willy

Received on Friday, 16 July 2021 16:48:08 UTC