You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1998/02/17 07:16:59 UTC
Re: Accept-Encoding - the saga continues (fwd)
>I WANT TO SHOOT WHOMEVER CREATED THIS STUPID X- "CONVENTION"!!
Join the crowd. The amazing thing is that every six months or so
I have to explain to some IETFer why it is so utterly stupid, just
so it won't be added to yet another spec.
>Anyway, this to me sounds like a case for a BrowserMatch, so I've added
>such a beast to the patch. Usage:
>
>BrowserMatch "MSIE 4\." strip-ce-header
>
>If strip-ce-header set, the fixup handler will remove any Content-Encoding
>header that might have been set. Note that I'm not sure exactly which
>versions of MSIE exhibit this problem. Also, I think this should be put in
>the known_client_problems page, and not as a part of the default srm.conf .
Nope, -1 on this part. There is never going to be a browser bug which
is so bad that it forces Apache to knowingly send the wrong HTTP fields.
If the C-E is removed, the Content-Type must be changed.
....Roy
Re: Accept-Encoding - the saga continues (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 20 Feb 1998, Anand Kumria wrote:
> On Wed, 18 Feb 1998, Martin Kraemer wrote:
>
> > On Mon, Feb 16, 1998 at 11:07:17PM -0800, Dean Gaudet wrote:
> > > - declare that this client is too broken for us to support it, and the
> > > client will need to be fixed. In this case it's only gsview that needs
> > > fixing as far as I can tell.
> >
> > IMO it's more a MSIE bug: it saves the file under an incorrect name
> > (even though it changes its contents, i.e., uncompresses it, the extension
> > stays the same). Way broken!
>
> Not really. If you as a user ask for a file to be downloaded wouldn't you
> be surprised if the filename you asked for doesn't appear (i.e. it gets
> renamed to <file>.ps instead)? gsview shouldn't be assuming that the name
> of a file has anything to do with the type of its contents.
No. If a file is a .gz file, it sure as hell better be gzipped.
If it is a .tar file, it should be a tar file.
If a client changes the format of a file, it should change the name to
reflect it.
If you do not have any extensions that map to types, you can argue that
you shouldn't change anything. However, if you do then it is bogus not to
change things.
In fact, what some Windows clients do is change foo.tar.gz to foo.tar_tar
and don't uncompress it.
Re: Accept-Encoding - the saga continues (fwd)
Posted by Anand Kumria <wi...@progsoc.uts.edu.au>.
On Wed, 18 Feb 1998, Martin Kraemer wrote:
> On Mon, Feb 16, 1998 at 11:07:17PM -0800, Dean Gaudet wrote:
> > - declare that this client is too broken for us to support it, and the
> > client will need to be fixed. In this case it's only gsview that needs
> > fixing as far as I can tell.
>
> IMO it's more a MSIE bug: it saves the file under an incorrect name
> (even though it changes its contents, i.e., uncompresses it, the extension
> stays the same). Way broken!
Not really. If you as a user ask for a file to be downloaded wouldn't you
be surprised if the filename you asked for doesn't appear (i.e. it gets
renamed to <file>.ps instead)? gsview shouldn't be assuming that the name
of a file has anything to do with the type of its contents.
Anand.
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
Re: Accept-Encoding - the saga continues (fwd)
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Feb 16, 1998 at 11:07:17PM -0800, Dean Gaudet wrote:
> - declare that this client is too broken for us to support it, and the
> client will need to be fixed. In this case it's only gsview that needs
> fixing as far as I can tell.
IMO it's more a MSIE bug: it saves the file under an incorrect name
(even though it changes its contents, i.e., uncompresses it, the extension
stays the same). Way broken!
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: Accept-Encoding - the saga continues (fwd)
Posted by Brian Behlendorf <br...@organic.com>.
At 01:53 PM 2/17/98 -0800, Roy T. Fielding wrote:
>>I think we have two choices:
>>
>>- agree that x-compress and x-gzip are the way things are and always will
>>be and we will always have to respond with those two (but we should
>>*NEVER* respond with x-anything else, unless AddEncoding is configured
>>that way, we should never help spread these stupidities)
>>
>>- declare that this client is too broken for us to support it, and the
>>client will need to be fixed. In this case it's only gsview that needs
>>fixing as far as I can tell.
>
>Either one is okay with me.
I'm cool with #2. We already bend over backwards for too many broken clients.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: Accept-Encoding - the saga continues (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 16 Feb 1998, Roy T. Fielding wrote:
> >I WANT TO SHOOT WHOMEVER CREATED THIS STUPID X- "CONVENTION"!!
>
> Join the crowd. The amazing thing is that every six months or so
> I have to explain to some IETFer why it is so utterly stupid, just
> so it won't be added to yet another spec.
Tell me where to email testamonials.
> >Anyway, this to me sounds like a case for a BrowserMatch, so I've added
> >such a beast to the patch. Usage:
> >
> >BrowserMatch "MSIE 4\." strip-ce-header
> >
> >If strip-ce-header set, the fixup handler will remove any Content-Encoding
> >header that might have been set. Note that I'm not sure exactly which
> >versions of MSIE exhibit this problem. Also, I think this should be put in
> >the known_client_problems page, and not as a part of the default srm.conf .
>
> Nope, -1 on this part. There is never going to be a browser bug which
> is so bad that it forces Apache to knowingly send the wrong HTTP fields.
> If the C-E is removed, the Content-Type must be changed.
Yeah I was reading over rfc2068 to figure out if there's anything we can
do. I don't think there is.
I think we have two choices:
- agree that x-compress and x-gzip are the way things are and always will
be and we will always have to respond with those two (but we should
*NEVER* respond with x-anything else, unless AddEncoding is configured
that way, we should never help spread these stupidities)
- declare that this client is too broken for us to support it, and the
client will need to be fixed. In this case it's only gsview that needs
fixing as far as I can tell.
Dean