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: conneg mods
Date Wed, 14 Aug 1996 02:05:40 GMT
> 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?

Fine with me.

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

Yep, that certainly was the intention prior to conneg removing the mxb
parameter of Accept.  It will work the way it was meant to work.

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

That is a reasonable start -- sending 406 without a list is conditionally
compliant, but sending 404 is not compliant.

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

That should be the goal.  Personally, I would prefer a better error
interface anyway, since we should not be killing persistence simply
because the server doesn't know the size of the error message (and
thus isn't sending content-length).

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

Yep.

......Roy

Mime
View raw message