Both represent a hashsum of the message body. Both can be used for checking if the resource was changed since the last time it was requested by a specific client. If they do identical thing, why do they coexist in the RFC2616 specification?
The Content-MD5 header is used by servers to provide a message-integrity check for the message body. Only an origin server or requesting client should insert a Content-MD5 header in the message. The value of the header is an MD5 digest of the (potentially encoded) message body.
An entity tag (ETag) is an HTTP header used for Web cache validation and conditional requests from browsers for resources. Etags use persistent identification elements (PIE) that have been tagged to the user's browser.
An ETag (entity tag) is an HTTP header that is used to validate that the client (such as a mobile device) has the most recent version of a record. When a GET request is made, the ETag is returned as a response header. The ETag also allows the client to make conditional requests.
Typically, the ETag value is a hash of the content, a hash of the last modification timestamp, or just a revision number. For example, a wiki engine can use a hexadecimal hash of the documentation article content.
Both represent a hashsum of the message body.
Not quite. Content-MD5
is a hash, but ETag
is an opaque identifier: the client doesn't know what it means. It's true that one way to generate an appropriate ETag
is by hashing the data of the resource, but it's certainly not the only one.
Both can be used for checking if the resource was changed since the last time it was requested by a specific client.
That's true, although in both cases you can theoretically get both false positives and false negatives.
If they do identical thing, why do they coexist in the RFC2616 specification?
The coexist because they serve different purposes; "they do identical things" is not true.
Content-MD5
is intended to let the client verify the integrity of the resource being transferred: its meaning is well defined, and it's not supposed to be used after the response has been received.
ETag
is intended to be used for coordinating caching. Being opaque it allows decoupling the semantics of a "resource identifier" from the its mechanics (so the server can choose to use any identification scheme it wants, and it's free to change this scheme in the future without the clients having any say on the process). Additionally, ETag
supports weak validation, allowing two bitwise-different versions of a resouce to be treated as semantically equivalent.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With