httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koen Holtman <>
Subject Re: [PATCH] Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Date Sat, 23 Jan 1999 13:45:32 GMT

On Fri, 22 Jan 1999, Roy T. Fielding wrote:

  [Koen Holtman:]
> >Look, we are talking a TCN *protocol violation* here.  We are not just
> >talking the possibility of getting a slightly degraded but still
> >acceptable response.  This protocol violation could potentially confuse
> >compliant browsers into producing a completely unacceptable response.
> Then fix the protocol.  TCN is experimental for a good reason.
> If TCN can get confused by a single correct 200 response, then something
> is wrong with TCN.  However, I think you are just inventing problems
> that do not exist in practice.
> >If you make Apache non-compliant to fix a non-compliance bug in Lynx, we
> >are worse off than we started.
> One has no effect on the other.  TCN recommends a whole bunch of crap
> that we are not going to do.  If you insist that we toe-the-line to
> every detail of the RFC when doing so has obviously adverse results
> for HTTP performance, then I'll just remove it from mod_negotiation
> and reduce the problem to the only one that needed to be solved:
> giving information in Alternates for agent-driven negotiation.

Two comments:

1) I had to take into account more than just your opinion when editing the
TCN spec.  If you think some features are crap, well other people thought
that sending a bulky Alternates header all the time was crap.  Tough.  The
RFC offers support for both views and this does imply that certain
responses can be incorrect if certain headers are sent.  I am not going to
revise the RFC so that it supports your view exclusively.  The RFC is good
enough and there is deployed (non-Apache) code which depends on it.

2) If you think you can win this argument about the bugfix sending `vary: 
user-agent' by threatening to outright nuke useful Apache features which I
(and others before me) spent considerable time developing, you are of
course exactly right.

Do it your way.  Leave out the vary: user-agent.  I'll grant you that
it will only break a tiny fraction of responses at best.

> If you can come up with an actual scenario which is broken by the
> implementation, then I'll fix it, but not just because it needs to match
> the current RFC.
> ....Roy


View raw message