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?
Bingo.
>> On apache.org 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
(application/x-gzip)?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
