News You Can Bruise for 2008 August 26 (entry 1)

(2) Tue Aug 26 2008 18:23 Content-Encoding versus Transfer-Encoding: Today I discovered a "problem" where Apache's mod_deflate changes a resource's ETag value from "foo" to "foo"-gzip when compressing the representation. This problem has been a while in coming, and after some research I'm convinced that Apache's behavior is almost completely correct.[0] But very annoying. Your representations are transparently compressed on the way out, but then the client sends you values for If-Match and If-None-Match that you've never seen before. True transparency is a two-way street.

There are a number of ways to solve the problem. One way would be for Apache to magically strip the "-gzip" off the entity-tags when they come back in, but how is Apache supposed to know that that particular -gzip was one it added? So, as usual, the magic solution fails.

An alternative that appeals to me is to stop treating compression as an aspect of the representation such that having it or not having it means you need to change the ETag. Move it out of Accept-Encoding and Content-Encoding, and into TE and Transfer-Encoding. This is related to what I was saying last year, but I didn't make the connection between "this is part of the transmission, not part of the representation" and "this should be in Transfer-Encoding, not Content-Encoding." Or to quote the RFC, "the transfer-coding is a property of the message, not of the entity."

The problem with this is that Transfer-Encoding describes the transmission from one intermediary in a chain to the next, not the transmission from server to client. Similarly for TE and the transmission from client to server. Intermediaries are my RESTful weak point so I don't fully grasp the implications of this. If the client sends TE: gzip, the proxy can decide to get an uncompressed representation, look at it, and then compress it before sending it back to me. That hurts performance but everything still works, right?

Update: "That is why transfer encoding was invented in the first place."

[0] To be 100% correct it would change the ETag to "foo-gzip", since entity-tags are supposed to be enclosed in quotes.

Comments:

Posted by anonymous at Tue Aug 26 2008 20:10

See also Etag vs Encoding

Posted by anonymous at Tue Aug 26 2008 20:11

...or dammit, scratch that, only looked at first link *as I clicked* post.