httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@liege.ICS.UCI.EDU>
Subject Re: HTTP/1.1 and colons and things
Date Thu, 20 Jun 1996 03:05:21 GMT
> The HTTP/1.1 spec, as written, will cause all existing Apache servers to
> start returning 404 Not Found whenever such a negotiated image is
> retrieved.
> Unfortunately, I didn't get around to testing this until HTTP/1.1 was in
> last call, but... I'm worried.
> I see a couple ways around this:
> 1) We can add the colon-parsing ability to Apache 1.1 (it's a simple pach,
>    two lines; one in get_token() and one in get_entry()), and hope almost
>    everyone's using it by the time HTTP/1.1 browsers become common.
> 2) Complain to the IESG, and modify the HTTP 1.1 spec. Unfortuantely,
>    there's no good workaround; if there was, it'd probably be in the spec
>    to begin with.
> Is there something I'm missing? Roy? I sincerely hope so...

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

We have three choices:

  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.

  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.

  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.

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

I will need to make a statement on this by Friday, so please give me your
opinions ASAP.


View raw message