httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: cvs commit: httpd-2.0/docs STATUS
Date Fri, 11 Apr 2003 10:59:21 GMT
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


Mime
View raw message