You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/04/11 07:41:02 UTC
Re: cvs commit: httpd-2.0/docs STATUS
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
Re: cvs commit: httpd-2.0/docs STATUS
Posted by Glenn <gs...@netspace.org>.
On Fri, Apr 11, 2003 at 01:26:40PM -0500, William A. Rowe, Jr. wrote:
> 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?
+1
You and I know that .tar.gz.md5 is an md5,
and that .tar.gz is a gzip compresed tar archive
and that .log.gz is gzip-encoded text/plain
Allowing the user to specify the meaning of multi-extension strings
(longest match of the _end_ of the filename only), allows us to assign
appropriate content-type and content-encodings, not to mention
transfer-encodings.
It is all about how we want the client to handle the file. If I
precompress some large html files, I want a request for html.gz
to be content-type: text/html and transfer-encoding gzip (which
mod_gzip or mod_deflate could add, without having to do any
inline compression.) Same thing for .tar.gz.md5.gz (How's that
for an example!)
Cheers,
-Glenn
> *) Should we provide an example such as '.gze' to distinguish
> gzip-encoded documents from gzip content type documents
> (application/x-gzip)?
>
> Bill
Re: cvs commit: httpd-2.0/docs STATUS
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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
Re: cvs commit: httpd-2.0/docs STATUS
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: cvs commit: httpd-2.0/docs STATUS
Posted by Ben Laurie <be...@algroup.co.uk>.
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
Re: cvs commit: httpd-2.0/docs STATUS
Posted by Ben Laurie <be...@algroup.co.uk>.
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