From docs-return-5048-apmail-httpd-docs-archive=httpd.apache.org@httpd.apache.org Fri Apr 11 10:59:26 2003 Return-Path: Delivered-To: apmail-httpd-docs-archive@httpd.apache.org Received: (qmail 99467 invoked by uid 500); 11 Apr 2003 10:59:24 -0000 Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: docs@httpd.apache.org Delivered-To: mailing list docs@httpd.apache.org Received: (qmail 99432 invoked from network); 11 Apr 2003 10:59:23 -0000 Message-ID: <3E96A009.30402@algroup.co.uk> Date: Fri, 11 Apr 2003 11:59:21 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org Cc: docs@httpd.apache.org Subject: Re: cvs commit: httpd-2.0/docs STATUS References: <20030409201502.81003.qmail@icarus.apache.org> <20030409201502.81003.qmail@icarus.apache.org> <5.2.0.9.2.20030410103000.062ebbc0@pop3.rowe-clan.net> In-Reply-To: <5.2.0.9.2.20030410103000.062ebbc0@pop3.rowe-clan.net> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N William A. Rowe, Jr. wrote: > At 06:04 AM 4/10/2003, Ben Laurie wrote: > >>wrowe@apache.org 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: docs-unsubscribe@httpd.apache.org For additional commands, e-mail: docs-help@httpd.apache.org