Code change:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A client SHOULD NOT generate content in a DELETE request.  Content received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request. </del> <ins> Although request message framing is independent of the method used, content received in a DELETE request has no generally 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 (request.smuggling).  A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.  An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. </ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored

Related discussion:
text: In-band negotiation is the SEARCH method (or whatever it ends up being called); it would be strange for the WG to allow other methods of negotiation when it's working on how to accommodate this properly. Also, while we place the requirement on the client here, realize that the impact here is really on the server -- it must not require a request to have a body in order to interoperate, because that precludes the client from using otherwise conformant HTTP implementations and infrastructure.
How so? Could you please clarify that? Are you saying that intermediaries are allowed to drop the payload? Where do we say that?
This discussion is not about future code, but about existing, deployed code which currently works for people, and which IMHO is not strictly forbidden by the existing spec. In past discussions, we agreed on strengthening how we discourage this, but a "MUST NOT" is very different from a "SHOULD NOT". For instance, do you expect HTTP libraries that currently support request bodies on GET to stop doing that, although there's production code relying on it?
No, I'm saying that the pressure we see to allow bodies on GET is being placed upon clients by servers who create services that use it, doing so because they read the current ambiguous language and find enough wiggle room to think it's allowed and a good idea. This is because the power dynamic between a client and server is often unbalanced, especially for APIs. It does not work in an interoperable fashion on the scale of the Internet - which is what we're documenting. Those are private agreements. The fact that it's not strictly forbidden is how we got here. Not any time soon, but those libraries aren't supporting HTTP in doing so; they're effectively supporting the creation of new, HTTP-derived protocols. How about:
Not following. It does work for some people (maybe because they use HTTPS or control the request path by other means). Saying that if something does not work "on the scale of the Internet" then it's not "HTTP" or shouldn't inform our spec does not work for me. If this was the case, we really would need to start removing many more pieces from the protocol. Also, telling libraries that they should stop supporting a use case that was allowed (with care) in RFC 2616 and 723x and which is used in practice doesn't look right to me.