William A. Rowe, Jr. wrote: > 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.
I don't believe I am! > 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. Sure. > 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.) Well, one obvious answer to that is to also sign the unzipped tarball. But I agree that if the intent is to have the file arrive intact at the other end, we should not give it a content-encoding of x-gzip. > 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. Either is correct, surely - it depends on what you want to happen when the client receives it, right? > On apache.org we are always using the second case, AFAICT. Even when it is actually an md5? Now I'm confused! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
