httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject conneg mods
Date Tue, 13 Aug 1996 18:56:44 GMT
There are a couple of changes to mod_negotiation I'd like to see made
before the 1.2 release of Apache. We've discussed some of them before, but
I thought I'd bring them up again:

1. "Fixing" broken browsers. Namely, Netscape Navigator, for example,
sends for your basic request:

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

Now, what this means is that I have a GIF image of quality 0.3, and a PNG
image of quality 0.7, the PNG image will get sent, which is probably not
the desired behavior. We've discussed in the past forcing wildcard values
to low quality values, e.g. making */* have a quality of 0.01 and type/*
have a quality of 0.02.

The problem with this is, of course, that a user agent that *isn't*
broken, and knows exactly what it is doing, might be upset at us doing
this. Namely, a browser might send:

Accept: */*, text/html;q=0.1

Which would mean "send me anything, anything you want, but please to gosh
only send HTML as an absolute last resort." Which is perfectly valid. And
we don't want to screw that up.

Likewise, with transparent negotiation, the purpose of:

Accept: */*

changes from "I accept everything with a quality value of 1.0" to "I
accept everything with a quality value of somewhere between 0.0 and 1.0".

But we still would like to make the broken browsers work, without
sacrificing future functionality, and without resorting to User-Agent
based changes (which IMHO we should use as little as possible - the
keepalive thing is ok, since it's really a bug bug, this isn't, it's just
an undesired behavior).

So how's this: we assume that if a user agent knows what it's doing, it
will assign at least one of its accept entries a quality value. So we look
at the Accept: header, and if none of the entries have a q-value, we are
permitted to modify the wildcards. Otherwise, we leave it alone. Likewise,
once transparent negotiation is implemented, we would leave it alone if a
Negotiate: header (or whatever the final form will be) is present.

I think this is an acceptable solution. What do other people (esp. Roy)
think?

2. Let's take the Netscape example again, simplified:

Accept: image/gif, image/jpeg

Now, we have an image available, conveniently enough, in GIF and JPEG
form. They're both the same quality value - they look the same to us, and
as we can see from the Accept: header, Netscape doesn't care which one we
send - they're both the same to it.

So how do we decide? Currently, we look at the order in the accept header.
image/gif comes before image/jpeg, so we send the GIF. This seems
pointless; if the browser really perferred GIF over JPEG, it would send:

Accept: image/gif, image/jpeg;q=0.8

or somesuch. So why do we pick the first one? It seems to me like it would
make more sense to choose, if there are no other cirteria, the smaller
file (save bandwidth). Apache does do this, but only if the files are of
the same type. i.e. if you're negotiating between foo.jpg and foo.jpeg.
How about moving that check up in precedence, so that if two files have
the same q-value, the same qs-value, match the same languages, etc, the
smaller file gets it?

3. If a user agents sends:

Accept: image/gif, image/jpeg

and all we have are a TIFF and a PNG, Apache sends 404 Not Found. This is
obviously wrong, because the file was found. The proper response code is
406 Not Acceptable. It should be trivial to change this, but there is one
issue:

However, the spec says "he response SHOULD include an entity containing a
list of available entity characteristics and location(s)  from which the
user or user agent can choose the one most appropriate." Spyglass' server
does this, for example.

This makes sense. If it's a human-readable request, they might like to be
able to select the PNG version, and save it to disk.

However, due to the way Apache handles 'errors', there isn't a good way of
doing this. So, in the meantime, is it acceptable to just send a 406
*without* such a list? Just say "The request was located, but a variant
could not be found which was appropriate for your user agent." or some
such?

Or should I figure out a way to smuggle the data from mod_negotitation
into send_error_response()? (becuase that's the only way to do it,
really)

Just some random thoughts. The language-tag matching thing also needs
fixing (en-US has to match en, not just en-US).

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




Mime
View raw message