> > 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
of the contained information will be sent to the browser instead.
Here's a diagram:
file.txt -> FProxy -> file.txt.gz -> Fred
Fred -> file.txt.gz -> FProxy -> file.txt -> lynx
text/plain -> FProxy -> application/x-gzip -> Fred
Fred -> application/x-gzip -> FProxy -> text/plain -> lynx
This feature can be added as an optional transparent addition to some
clients and be backward compatible with all existing clients. Some clients
can just be nice and automatically zip your stuff for you. Some clients
can be nice and automatically unzip your stuff for you. If you use other
clients, you'll have to zip it yourself and when you download it you'll
just get a zip file. But these clients won't be broken because they don't
understand the new metadata field, they'll just not have that nifty
feature where they automatically unzip the file for you.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
