Tighten language around GET request bodies (Mnot 202)

[mnot]

Fixes #202.

[reschke]

Not sure about havign a new normative requirement for DELETE. Did we agree on this.

That said, we also need to mention the normative change for GET in "Changes from 7231".

[royfielding]

For editorial consistency, I have been removing cases where requirements are applied to plurals or to larger-than-necessary scope. In this case, I think it should be

   A payload within a GET request message has no defined semantics.
   A client SHOULD NOT generate a payload body in a GET request.
   Sending a payload body on a GET request might cause some existing
   implementations to reject the request.

[mnot]

I'm fine with that; it was borderline.

[reschke]

1. This is a new normative requirement on GET; good, but needs to be mentioned as a change.

2. The change on DELETE is not what we discussed in the WG. I propose to take this out here and move it into a separate issue.

[mnot]

Change note added.

Creating a new issue doesn't make any difference; they're just how we track what we need to do.

IIRC there was one person who mentioned an existence proof of a DELETE body -- which is very analogous to the situation with GET. We know that some people do them, but we also know that they're not interoperable, and this is not an intended extension of the protocol.

[reschke]

I strongly believe that the issues for GET and DELETE are very different, and that handling them in a single ticket is harmful.

Can we please focus on GET first?

[mnot]

Please update the PR and create the issue, then.

[reschke]

will do.

[asbjornu]

Would it be possible to mention the problems around caching with a body on GET requests? As GET with a body is in use by large vendors such as Elasticsearch (see elastic/elasticsearch#16024) and their interpretation of the spec being that this is "just fine" (see elastic/elasticsearch-php#737 (comment)), I think a stronger language should be used to discourage implementations from using a body with GET requests.

This also brings up what we discussed at the HTTP Workshop in May around creating a header to declare that the request body should also be considered a part of the cache key, as well as the possibility of creating a new SEARCH method (currently drafted by @jasnell).

[reschke]

@asbjornu - the pull request has this:

A payload within a GET request message has no defined semantics. A client SHOULD NOT generate a body in a GET request. Sending a payload body on a GET request might cause some existing implementations to reject the request.

IIUC, you'd like this also to mention other failure modes such as GET request suceeding, but result might be inproperly cached?

(the other points IMHO are out of scope for the HTTP core revision; maybe they should be tracked in the http-extensions repo instead).

[asbjornu]

@reschke:

IIUC, you'd like this also to mention other failure modes such as GET request suceeding, but result might be inproperly cached?

Yes, exactly. Just as an informational warning so implementers understand the dangers they are putting themselves into by ignoring "SHOULD NOT".

(the other points IMHO are out of scope for the HTTP core revision; maybe they should be tracked in the http-extensions repo instead).

Should I create an issue for SEARCH and one for a cache header in the httpwg/http-extensions repository?

[reschke]

1. Ack. @mnot ?

2. Yes.

[asbjornu]

@reschke: Ok, httpwg/http-extensions#942 and httpwg/http-extensions#943 created.

[reschke]

"... or might cause surprising effects in HTTP caches which ignore the payload."

[royfielding]

caches that ignore the request payload? I'm not sure what you mean here.

[reschke]

A cache might just pass the request payload to the server, but then cache the result despite the fact it might vary on the request body. So that kind of failure would only be indirectly observable.

I think it's worth pointing this out...

[mnot]

perhaps "... or might cache caches to reuse the response erroneously."