httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Metadata for .tar.gz
Date Tue, 04 Feb 2003 19:14:14 GMT
[Suggestion, reply to docs@ and let's spare dev@ the bandwidth
since this is mostly an admin/user issue.]

I almost forgot an 'extra' interaction...

If we set up content-type application/x-tar with the proper
content-encoding of gzip we end up with even WIERDER
browser behavior...

Consider that foo.tar.gz has those headers ... the type of
the file really is an x-tar that has been gzip compressed.

So now the friendly browser takes foo.tar.gz and decides
that the file is really, really a .tar, but it only looks at the
last extension.  That extension isn't .tar so it either;

  * truncates from the first period and adds .tar
  * truncates from the last period and adds .tar
  * appends .tar to the name.

And furthemore the browser may;

  * unpack the .gz content so the value of any .md5 or .sig/.asc
    associated with the original file is now meaningless

Aren't user friendly tools way to helpful these days :-?

I would *really* love to get feedback from the client developer
communities about how on earth an admin or web developer
should prepare for this.  But I honestly don't have cycles to
engage the MozDev team or any others in such a discussion.

Of course IE understands the Content-Disposition header.  What's
sad is that header is from MIME mail RFC 1806, not HTTP.

I'm almost ready to hack a module to add Content-Disposition
munging so that IE quits trying to save "myscript.pl" as a perl
script (when myscript.pl returns content-type text/plain or
application/octet-stream.)  Only to make IE users shut up already
about their broken browser.  (The hack: when responding with the
myscript.pl request as text/plain results, send this convoluted 
header:   Content-Disposition: inline; filename="myscript.txt"
which forces the browser to treat it, by filetype, as .txt output.
Since everyone else ignores such a bogus header, it should be
a mostly harmless hack.)

One such thread on the Content-Disposition topic;

http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0048.html

Bill




At 12:20 PM 2/4/2003, William A. Rowe, Jr. wrote:
>An answer to a user question (and a gripe from me since I've hit this
>problem myself on apache.org);
>
>> [the links] point to .tar.gz files, which exist.  When they are clicked on,
>> however, they are being renamed to .tar.tar files. Any ideas?
>
>Renamed by the browser, not the server.
>
>Check in mime.types that we have content types for .tar *and* .gz.  The
>default defines only .tar, so we return application/x-tar.  If it included .gz,
>the *final* pathname element determines the mime type, which would
>be application/x-gzip.
>
>Almost makes you wish for application/x-gtar or something.  You can only
>count on gnu tar to support tar -z.
>
>Anyways, because the content type is application/x-tar, and the browser
>sees the *final* extension is .gz, it is choosing to replace .gz with .tar or
>even adding another .tar (e.g., .tar.gz.tar which I've seen also.)
>
>Seems like the ASF needs to choose between removing application/x-tar
>or adding application/x-gzip in the default mime types.  Sure, we have a 
>general policy against adding x- extentions, but by adding one, we open
>ourselves up to problems. :-)
>
>Bill



Mime
View raw message