httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: Negotiation updates, and transparent neg.
Date Tue, 20 Aug 1996 18:51:14 GMT
On Tue, 20 Aug 1996, Paul Sutton wrote:

> > 2) I have question about when it sends choice responses as opposed to list
> > responses with transparent negotiation. It seems to send the former a lot
> > more than it should. But I haven't looked further into why or how.
> 
> Maybe bug.

I think it has to do with Koen's spec (surprise). The problem is that, as
I recall, if you find a "best match", you should send it as a choice
response. The problem is that the defenition of "best" is a bit hazy. For
example, as I recall (and this may be from an earlier version of the
spec), if you have two variants, image/gif;qs=1.0 and image/jpeg;qs=1.0,
and the user sent "Accept: */*", they get a list response. On the other
hand, if they sent "Accept: image/gif;q=1.0, image/jpeg;q=0.5", they get
the GIF. However, if they send "Accept: image/gif;q=1.0,
image/jpeg;q=1.0", the server should send them a choice response. This
seems wrong - the GIF and the JPEG should both have equal quality, and the
server (IMHO), should send a 300.

> > 3) A lot of the changes I made on Friday no longer work (this is now
> > without transparent negotiation). Namely:
> >
> > a. en-US has to match en, not just en has to match en-US.
> 
> Non-bug... I think HTTP/1.1 is clear on this: you can only match on
> prefixes of the language-tag (from the variant), not on prefixes of the
> language-range (from the accept-language header):
> 
>     "A language-range matches a language-tag if it exactly
>      equals the tag, or if it exactly equals a prefix of the tag such
>      that the first tag character following the prefix is "-"." [14.4]
> 
> Unless I've got this the wrong way round in the code, this is what it
> should be doing. A request for en should match en and en-US, but a request
> for en-US should not match en.

I disagree. Consider a browser (mine, for instance) which sends
"Accept-Language: en-US". They should be able to speak plain English. The
spec may be wrong on this point, I'm not sure.

[...]

> > 4) If I'm negotiating between, say, foo.gif and foo.gif.gz, it does not
> > set "Vary: accept-encoding", which it should. It does set it when
> > negotiating between foo.gif.Z and foo.gif.gz
> 
> Um, the intention is that if doing trans neg, Vary never includes
> 'accept-encoding' (Holtman [4.6] explicitly excludes encoding from trans
> neg). I'm not sure whether this is a good idea, since it implies the
> server can return encodings the UA cannot handle, but that is what it
> says.

Well, for one thing, this is with server-driven negotiation, not
transparent. For the other thing, as Roy points out, Koen is a bit messed
up. Actually, his draft does *not* exclude encoding. The way I understand
it is this: The server is supposed to pre-cull encodings before going to
the transparent negotiation phase, on the assumption that an
Accept-Encoding: header (or lack thereof) is absolute. Therefore, if I
have an unencoded variant, a gzipped one and a compressed one, I should
pick the best one, based on Accept-Encoding (and set the Vary: header
thus) and then use that in the Alternates: header, completely ignoring the
others. This has some problems, but is how I understand Koen means it.

Thanks!

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