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: Negotiation updates, and transparent neg.
Date Tue, 20 Aug 1996 10:07:41 GMT
>> 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.

Koen's draft sucks, and that's being nice.  It continually astounds me
how he manages to make things more difficult by breaking the most obvious
abstractions in the protocol.  Transparent negotiation will include
content-encodings before it goes anywhere, because two variants of the
same resource which differ only by content-encoding need to be differentiated
somehow in order for the rest of his algorithm to work.  In any case,
its stupid to leave it out.

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

No, use 406.  It may not be defined in RFC 1945, but it is a valid HTTP/1.0
response code and all HTTP/1.0 applications may be capable of understanding
it without implementing other parts of HTTP/1.1.


View raw message