W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Re: #904: Content on GET requirement strength

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 23 Jul 2021 11:56:54 +1000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C342EF3E-9A90-48E7-9BAF-5853C151D548@mnot.net>
We seem to have converged on a resolution here:
  https://github.com/httpwg/http-core/pull/906

Please take a look and if you have questions, comments or objections, let us know.

Cheers,

> On 16 Jul 2021, at 5:06 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> <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/
> 
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 23 July 2021 01:57:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 23 July 2021 01:57:19 UTC