httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@ukweb.com>
Subject Re: Negotiation updates, and transparent neg.
Date Tue, 20 Aug 1996 07:41:03 GMT
On Mon, 19 Aug 1996, Alexei Kosut wrote:
> Patching in this patch, and testing it, I've noticed (after about two
> minutes) several things which are simply wrong
>
> 1) When it sends what should be a 300, the first line of the response is:
>
> HTTP/1.0  200 206 301 302 304 400 401 403 404 405 406 411 412 500 503 501
> 502 506
>
> This seems wrong.

Bug!

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

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

> b. The smallest variant should get chosen, in the absense of other
>    consideration. Namely, if I have a three-byte GIF and a four-byte JPEG,
>    and send a request with "Accept: */*", "Accept: image/gif, image/jpeg"
>    or without an Accept: header, it sends me the JPEG. It should send the
>    GIF.

It should be doing this. Must be a bug.

> c. Wildcard tweaking. We need this. "Accept: */*, image/gif" for the same
>    variants sends the JPEG. The algorithm I used (if there are no q-values
>    (or Negotiate: headers), make */* have a quality of 0.01 and type/*
>    a quality of 0.02) has been carefully tested in a number of scenarios
>    with current browsers.

Yes, I think this is a good idea, and no my code doesn't do it. I'll apply
your patch.

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

> 5) I don't know why you did this, but you replaced 406 with 404 for
> pre-HTTP/1.1 responses. 406 is perfectly fine to send to HTTP/1.0.

Because 406 is not defined in HTTP/1.0, so a 1.0 UA treats it as 400 "Bad
Request" which has different semantics from a 404 "Not Found" (in
particular, a 400 response tells the UA to not repeat the request without
modifications, whereas a 404 can mean temporarily unavailable. I guess I
just think it is cleaner to not change existing behaviour as seen by 1.0
UAs, just in case there are any unintended side effects.

> There are probably other things: in general, the code looks very good,
> nice, clean and commented. However, its behavior seems wrong a good part
> of the time. I'm not quite sure why this is, but it does.

Gee, thanks! I'll try and fix the problems asap.

Paul
UK Web Ltd


Mime
View raw message