httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: cvs commit: httpd-2.0/docs STATUS
Date Fri, 11 Apr 2003 18:26:40 GMT
At 05:59 AM 4/11/2003, Ben Laurie wrote:
>William A. Rowe, Jr. wrote:
>> [...] you are falling into the trap of mixing content-type and content-encoding 
>> here.
>I don't believe I am!

Ok... so let's look at the tail of the remaining issues...

>>  About the only thing we could introduce is support for a directive;
>>   AddContentEncoding: identity
>> 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.

Right.  We can react two ways here...

one, grow the ability for an extention such as tar.gz (if they occur seqentially
in that order) for our Add{MimeProperty} directives.

two, don't use .gz for both type: application/x-gzip and encoding: x-gzip.
That seems pretty obvious to me... you can't have things both ways.

And I suggested that we might want to define .gze for files that aren't reallly
'application/x-gzip', but really encoding of x-gzip.  It wouldn't replace the
content-type at all... so take my example below, name it my.log.gze and
you force it to use to the first case below (assuming content-type for .log
is set up text/plain)...

>> 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 we are always using the second case, AFAICT.
>Even when it is actually an md5? Now I'm confused!

No... the last extention we encounter overrides previous extentions
matching mime fields.  So, md5 today replaces any other content-type
with text/plain (or could use text/x-sig, etc).  

What was broken was that md5 changes the content type, but doesn't
affect the content encoding field.

So the remaining questions;

*) Do we want to support AddContentEncoding: identity?
   (and have the headers-core remove the content-encoding tag identity
    before transmitting the headers, to comply with the rfc).

*) Do we want to support 'multi-extention' Add{Foo} directives - such as
   the combination tar.gz or other combined meanings?

*) Should we provide an example such as '.gze' to distinguish 
   gzip-encoded documents from gzip content type documents 


View raw message