RE: #904: Content on GET requirement strength

I'm supportive of your perspective that GET (which is already defined to place no semantic value on the body) is not compatible HTTP when sent with content.  However, the http-core docs' practice has been to avoid making existing uses newly non-conformant.  This is the third generation of these specs, and late in the process at that.

As I've added on the issue, I feel like this is converging on a "MUST NOT unless."  There is a narrowly scoped situation in which this can be done -- prior arrangement with all parties -- and it's otherwise prohibited.  That captures both the strength of our guidance not to do this, but also the reality that some people already do and presumably don't plan to stop.

That said, I don't feel like this is a hill to die on.  The spec says this is not good behavior, and explains why.  The explanation of the SHOULD NOT could simply be the existence of resources which define private semantics to GET content.  Clients interacting with such resources will have to choose whether to bow to the API definition.

-----Original Message-----
From: Mark Nottingham <mnot@mnot.net> 
Sent: Friday, July 16, 2021 3:07 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: #904: Content on GET requirement strength

<https://github.com/httpwg/http-core/issues/904>

Currently, we have consensus around the following text in Semantics:

> 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]).

<https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#GET>

In her review, our AD pointed out that it's good practice to explain the conditions under which a SHOULD NOT be violated -- generally, if we can't do so, it's a sign that the requirement isn't well stated.

In discussing this, we haven't yet been able to come up with such an explanation. So, the current proposal is to replace the text above with:

> A client MUST 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]).

Thoughts? If folks disagree, suggestions about how to qualify the SHOULD NOT would be appreciated (see the issue for some options already discussed). 

Alternatively, if we can't come to relatively quick consensus on MUST NOT or a qualification for SHOULD NOT, we could consider leaving it as an unqualified SHOULD NOT - the AD comment isn't blocking. Not terribly good editorial practice, but I'm pretty sure we've done worse somewhere.

Cheers,

P.S. The same adjustment would be made on HEAD and DELETE, since we've tried to align their language regarding this behaviour.


--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 16 July 2021 14:34:10 UTC