Date: Wed, 19 Jun 1996 22:07:32 -0700 (PDT)
From: Alexei Kosut <akosut@organic.com>
To: new-httpd@hyperreal.com
Subject: Re: HTTP/1.1 and colons and things 
In-Reply-To: <9606192005.aa29441@paris.ics.uci.edu>
Message-ID: <Pine.SOL.3.93.960619215903.17285A-100000@acidik.organic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Wed, 19 Jun 1996, Roy T. Fielding wrote:

> *sigh* I knew that would come back to haunt me.  I had bad feelings about
> that change, and voiced them in Paris, but I was assured [by non-httpd
> people who I no longer consider reliable] that it wouldn't affect
> existing systems because clients (except Spyglass) don't sent parameters.

Tell these non-httpd people that:

a) The problem isn't current clients (since HTTP/1.1 servers can always
accept semicolons to be backwards-compatible), but future clients (since
we can't change the quarter million web servers already in existance.

b) They're wrong anyhow. Lynx sends paramaters. NCSA Mosaic (versions 1.x)
sent parameters. So did half a dozen other browsers that used to be
popular pre-1994. Netscape Navigator doesn't send paramters. That's what
they mean.

>   1) Absorb the change for the sake of "the future extensibility of Accept".
>      That means we absolutely must parse for ":" before 1.1 goes out
>      (we may want to do this anyway, just in case) and then strongly
>      encourage people using multiviews to upgrade.

Unfortunately, one of of every thirty web servers is still running NCSA
httpd 1.3 - a server that's known to have a huge security hole the size of
Utah. The 60,000 people running 1.0.5 and earlier will no doubt upgrade at
about the same rate.

Though we can certainly add colon-parsing to 1.1. That's simple.

>   2) Go to the HTTP WG and require that the ":" not be sent to
HTTP/1.0
>      servers, since it now represents an incompatible change to the protocol.
>      Note, however, that this sucks -- HTTP/1.1 servers would be required
>      to support the older syntax.

It doesn't suck that much. The current spec's BNF, I believe, does allow
for both.

>   3) Go to the HTTP WG and require that the ";" separator be restored,
>      and that the first parameter named "q" always separates the media
>      type from the negotiation parameters.  Come to think of it, this
>      is what the conneg group should have decided in the first place.

Agreed. This is, at least, a workable solution, though not quite elegant.
(though better than a lot of protocol decisions I've seen elsewhere).

> So, what is our decision?  (3) is probably the best in terms of protocol
> compatibility and ease of parsing, assuming that no media type ever uses
> "q" as a parameter name (which would be extremely unlikely anyway).
> However, it would reset the last call and delay the protocol by a month
> (due to the Montreal meeting being next week).

Yuck. Yuck. Yuck. I knew I should have tested this earlier. Out of
curiosity, how do the CERN and Spyglass servers (both of which do
content-neg currently, I believe) deal with colons?

-- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
   http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/