Date: Wed, 18 Feb 1998 00:57:19 +0200
Message-Id: <98021800571972@psiclb.psi.ch>
From: Ronald.Tschalaer@psi.ch (Life is hard... and then you die.)
To: dgaudet@arctic.org, NEW-HTTPD@apache.org
Subject: Re: Accept-Encoding - the saga continues (fwd) 
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


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


  Cheers,

  Ronald