HTTP/1.1 and colons and things

[Alexei Kosut <ak...@organic.com>]

Hmm...

I finally got around to checking into something that's been sitting at the
back of my mind regarding the HTTP/1.1 specification, kind of festering...

At any rate, the spec says that in HTTP/1.1 Accept: headers, quality
values should be seperated with colons (:) instead of semicolons (;), as
they were in HTTP/1.0. This is to seperate quality values from media type
arguments (like level and what have you).

However, Apache's negotiation module, which was written way back when,
doesn't like colons. I just checked this, and it really doesn't. If you
feed an Apache server:

Accept: text/html;q=0.7

then it (as it should) picks up that you mean you'd accept an HTML
document, text/html with a 30% reduction in quality.

However, if you feed it:

Accept: text/html:q=0.7

which is the perferred syntax in HTTP/1.1, then it thinks you mean that
you'd accept a file of type 'text/html:q=0.7" with a 0% reduction in
quality.

Now, obviously, this is bad. You might think "okay, so it might result in
wrong choices by the server, but it can't be any worse than what happens
with the Accept: headers browsers send now". Wrong. True, if the request
contains a "*/*", because Apache just looks for the first "*" and assumes
the rest, you'll at least get something, so it'd be okay for that (i.e.
what Netscape et al. send now for organinary requests).

But not for everything. Here's an example of where things get really
really bad. Let's pretend that you had a negotiated image. You had
a GIF and a JPEG version. Now, currently, Netscape 2.0/3.0 sends for
inline images:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg

Which isn't great, because it doesn't tell you if it'd perfer the GIF of
the JPEG, but at least the server will serve one or the other. Okay, so
far so good. But let's say Netscape gets with the program, and a future
version of Navigator sends:

Accept: image/gif:q=0.7, image/x-xbitmap:q=0.5, image/jpeg:q=0.8,
        image/pjpeg:q=0.9

You might be thinking "okay, so what's the big deal? It'll still get
something, right?" Wrong. Because none of those colon-ized types are known
by the server, it'll respond with a 404. (it would have been a 406, but a
year ago, there was no 406 spec to code to). Oops. This is a Bad Thing.

Since image negotiation is currently the one place where content
negotiation actually works with popular browsers, I believe a lot of sites
are using Apache in just this manner.

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

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