At 06:04 AM 4/10/2003, Ben Laurie wrote: >[EMAIL PROTECTED] wrote: >>wrowe 2003/04/09 13:15:02 >> Modified: docs STATUS >> Log: >> Please consider and vote - see what this choice has done to us >> r.e. .tar.gz.md5 files and so forth. > >This seems totally wrong-headed to me. The problem is that we are making the >assumption that file extensions indicate cascaded _reversible_ processes that >have been applied to the file. However, that is not always the case. It seems >quite straightforward, in English at least, to understand that: > >x.tar.gz > >means we tarred some stuff then gzipped it, so to get the original stuff back >we should unzip then untar. Likewise: > >x.gz.tar > >would mean to me we gzipped and then tarred something. However: > >x.tar.gz.md5 > >clearly is a non-reversible transformation, so the only interesting thing >about it is the fact that its an MD5. > >x.tar.md5.gz > >or even: > >x.tar.gz.md5.gz > >make sense to me - a gzipped MD5. It seems to me we need to improve our >understanding of file extensions, not kludge our way around them.
Again, you are falling into the trap of mixing content-type and content-encoding here. About the only thing we could introduce is support for a directive; AddContentEncoding: identity Which you could apply to the md5/asc tags. Now that would be an absolute determinant that the content is text-plain, not gzipped. But this isn't the end of the problem. We would have to strip the content-encoding field entirely if it devolves to identity; 'identity' is only supported in the Allow-encoding header, and RFC2616 clearly documents that the server should *NOT* send it to the client. But the biggest issue is that we should never be sending those files as gzip encoded. You really want to have to re-gzip the file you just downloaded in order to check it's pgp signature, because your browser automatically un-gzips based on content-encoding? (They generally will, by the rfc.) my.log.gz - what headers should that have? It must either be; Content-Type: text/plain Content-Encoding: x-gzip -or- Content-Type: application/x-gzip And of these two different responses to the browser, 98% of the world is expecting the later. For the other 2% - the former can be enabled (and directives will be left, commented out) and is certainly very useful. On apache.org we are always using the second case, AFAICT. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
