What constitutes "identical" for the purposes of HTTP idempotence?

Question

From RFC 7231 "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" Section 4.2.2 "Idempotent Methods":

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

RFC 2616 has similar text.

However, the term "identical" is defined in neither RFC.

It seems reasonable to assume that two requests that are literally identical, byte for byte, in all content (including headers and body) would be identical for this purpose.

It also seems clear that extrinsic properties of the request, such as the time it was sent (as long as it is not represented in the request), would be irrelevant to the "identical" disposition of the request. Otherwise idempotence would be a meaningless distinction.

However, are there any possible differences whatsoever between two requests, even for example differences in a single particular header, for any of the idempotent HTTP methods, that could nonetheless still constitute identical requests for the purpose of idempotence?

It seems to me that RFC 7231 or RFC 2616 alone do not answer this question directly, but I wonder if there is an RFC, specification, or otherwise generally authoritative source that does specify the answer to this question.

Or if a widely used dependent system (such as a highly utilized HTTP client or server) documents its expectations around "identical" for the purposes of idempotence, that would be fairly helpful as well.

Answer 1

I believe your answer is in RFC 7231

Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response.

That is the motivation - we are distinguishing messages with semantics that support automated retry from methods without those semantics. That we all agree a particular method is idempotent means that we can attempt an automated recovery without concern for loss of property that might otherwise arise if the server were to receive multiple copies of the message.

As best I can tell, there isn't a lot of money in supporting a case where the messages are "almost" copies of each other; therefore, that's left as an exercise to the reader.

---

One of the important ideas in REST is that the messages are self-descriptive, so the extrinsic properties you mention are effectively out of bounds as far as interpreting the semantics of the message are concerned.

What about headers? RFC 7230 makes clear that changing the order of the headers does not change the meaning of the message. There's also a long discussion of protocol versioning; in effect, two messages might have the same meaning even though one only contains a subset of the headers of the other (because the message needs to be understood by recipients and intermediaries that don't recognize the new features).

Changing the value of a precondition header potentially changes the meaning quite a bit; changing the value of a User-Agent header changes the meaning of the message almost not at all. So maybe you have to take the headers on a case by case basis? within the context of the primary source of request semantics, of course.

Beyond that...? I don't think you are going to find precise definitions; if two concerns with financial resources collide in court over one of these things, the lawyers are going to get rich.