httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Life is hard... and then you die.)
Subject Re: Accept-Encoding - the saga continues (fwd)
Date Tue, 17 Feb 1998 22:57:19 GMT

> > >Anyway, this to me sounds like a case for a BrowserMatch, so I've added
> > >such a beast to the patch. Usage:
> > 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.

Yea, Roy is right (of course). Ok, just remove the 4 lines in the patch
pertaining to the strip-ce-header env var. I'm not particularly unhappy
about this hack being turned down...

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

Hmm, my patch will cause Apache to respond with "C-E: x-hello" if the
browser sent "A-E: x-hello". I.e. there is no explicit test for compress
and gzip (I just hate hardwiring things). I agree that Apache shouldn't
endorse this x- nonsense, but I think giving the browser what it asked
for goes under the heading of "Be liberal in what you accept".

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

gsview or IE, or both (or, even better, M$).



View raw message