httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Accept-Encoding - the saga continues (fwd)
Date Tue, 17 Feb 1998 07:07:17 GMT
On Mon, 16 Feb 1998, Roy T. Fielding wrote:

> 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. 


View raw message