> No, I'm saying that FProxy should do the right thing w/r/to a web browser. > Other clients may or may not need to perform automatic decompression at > layer X. How can adding a feature to FProxy break all existing clients?
You're not proposing a feature addition to FProxy, you're proposing a new metadata field and an addition to FProxy. Here's the metadata of two files: ContentType=text/plain ContentType=text/plain ContentEncoding=gzip Read by an old client, these look the same. The second is actually a gzip file. Therefore old clients will be broken with respect to handling files that contain the ContentEncoding field since they don't know what that is. On the other hand, you could have ContentType=text/plain ContentType=application/x-gzip This is backwards compatible with old clients. They simply can't tell the difference between a zip file and a text file which was automatically zipped on insert, which is much more reasonable than thinking that zip files are actually text files. > You're right. That is so much simpler and transparent than, say, adding > a ContentEncoding field to the Info metadata. I didn't say it was simpler, I said it was the right way, based on several principles. First don't break old clients when you can help it. Second don't add things to the specifications because it's useful or natural for one of the implementations. As far as I can tell, the
