Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030410103000.062ebbc0@pop3.rowe-clan.net>
Date: Fri, 11 Apr 2003 00:41:02 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: cvs commit: httpd-2.0/docs STATUS
Cc: docs@httpd.apache.org
In-Reply-To: <3E954FD9.9060807@algroup.co.uk>
References: <20030409201502.81003.qmail@icarus.apache.org>
 <20030409201502.81003.qmail@icarus.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"


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.  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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org