> > Why not just use the Content-Type field and set it to application/x-gzip? > > Why add another metadata field? > > Because that's actually a technically wrong use of Content-Type. I forget > which RFC I read about this in, but it was one of the HTTP or MIME ones. > Content-Type is supposed to be set to, well, the content type, which is > independent of how the content is encoded .. hence the Transfer-Encoding > header in HTTP.
The metadata field is not an HTTP header field, it is a Dublic Core metadata field. When using FProxy, an HTTP header field with a confusingly similar name is generated in order for FProxy to act appropriately as a web proxy. However, the meanings of HTTP header fields with similar names is totally irrelevant to the metadata standard, which is not based on HTTP. So arguements about misusing the meanings of headers are irrelevant. The question is, do we need an encoding header in addition to a content type header? I don't think we do, as explicated below. > Think about it, how can the browser distinguish HTML from text or > anything else if you put application/x-gzip in the ContentType? If the content is sent to the browser zipped, then it's not text or HTML, it's gzip. If the content is automatically unzipped by the client (FProxy if we're talking about interfacing to a web browser) then the content type
