PHWinfo - Afficher un message - content-type versus content-encoding

18/07/2006, 19h48

On Tue, 18 Jul 2006, Nick Kew wrote:

> Alan J. Flavell wrote:
> > I'm trying to get optimal results for files whatever.ps.gz (to
> > take an example). If it's relevant, Apache version is
> > 2.0.46-something, as distributed by RHEL.
>
> Does it have a configuration section looking something like
[...]
> # AddEncoding allows you to have certain browsers uncompress
> # information on the fly. Note: Not all browsers support this.
> # Despite the name similarity, the following Add* directives have
> # nothing to do with the FancyIndexing customization directives above.
> #
> #AddEncoding x-compress .Z
> #AddEncoding gzip .gz .tgz
> #
> # If the AddEncoding directives above are commented-out, then you
> # probably should define those extensions to indicate media types:
> #
> AddType application/x-compress .Z
> AddType application/x-gzip .gz .tgz

Indeed it does. Could I suspect that the "Note: Not all browsers
support this" is now very old, and could more usefully say something
like "Note: a few browsers, by now little-used, don't support this."

But I'm puzzled that the RemoveType directive in the .htaccess didn't
take away the effect of the AddType directive in the main
configuration: the server evidently swallowed it without protest, but
"nothing happened".

> Fixing that should work just fine. A bug report complaining about
> silly defaults can't hurt.

If you mean that this is also the Apache distributed default, then OK.

But if this is some kind of RHEL-tailored httpd.conf, then I have to
admit we are using Scientific Linux, which is a clone of RHEL, meaning
that I have no right to submit bugs to RH.

thanks

By the way, while this topic is active, I seem to recall at least one
browser which, when presented with a file glorp.something.gz to
download, with content-type application/something and content-encoding
gzip, then the browser would dutifully unzip the object and then store
it in a file named, by default, glorp.something.gz

When the file was then presented to the "something" application (I
think it was tar, but I could be wrong), the application said (in
effect) I can't process that, the filename says that it's gzipped, but
I can see that it isn't.

Any chance that someone recognises this effect, and can say whether
the situation has changed? (Just a shot in the dark - I didn't think
it justified starting a new thread.)

18/07/2006, 19h48	#10
Alan J. Flavell Messages: n/a Hébergeur:	Re: content-type versus content-encoding On Tue, 18 Jul 2006, Nick Kew wrote: > Alan J. Flavell wrote: > > I'm trying to get optimal results for files whatever.ps.gz (to > > take an example). If it's relevant, Apache version is > > 2.0.46-something, as distributed by RHEL. > > Does it have a configuration section looking something like [...] > # AddEncoding allows you to have certain browsers uncompress > # information on the fly. Note: Not all browsers support this. > # Despite the name similarity, the following Add* directives have > # nothing to do with the FancyIndexing customization directives above. > # > #AddEncoding x-compress .Z > #AddEncoding gzip .gz .tgz > # > # If the AddEncoding directives above are commented-out, then you > # probably should define those extensions to indicate media types: > # > AddType application/x-compress .Z > AddType application/x-gzip .gz .tgz Indeed it does. Could I suspect that the "Note: Not all browsers support this" is now very old, and could more usefully say something like "Note: a few browsers, by now little-used, don't support this." But I'm puzzled that the RemoveType directive in the .htaccess didn't take away the effect of the AddType directive in the main configuration: the server evidently swallowed it without protest, but "nothing happened". > Fixing that should work just fine. A bug report complaining about > silly defaults can't hurt. If you mean that this is also the Apache distributed default, then OK. But if this is some kind of RHEL-tailored httpd.conf, then I have to admit we are using Scientific Linux, which is a clone of RHEL, meaning that I have no right to submit bugs to RH. thanks By the way, while this topic is active, I seem to recall at least one browser which, when presented with a file glorp.something.gz to download, with content-type application/something and content-encoding gzip, then the browser would dutifully unzip the object and then store it in a file named, by default, glorp.something.gz When the file was then presented to the "something" application (I think it was tar, but I could be wrong), the application said (in effect) I can't process that, the filename says that it's gzipped, but I can see that it isn't. Any chance that someone recognises this effect, and can say whether the situation has changed? (Just a shot in the dark - I didn't think it justified starting a new thread.)