Re: Call for compatibility testers

Roy T. Fielding:
>
>Read the description of 300 in the HTTP/1.1 spec:
>
>    10.3.1 300 Multiple Choices
  [...]
>    If the server has a preferred choice of representation, it SHOULD
>    include the specific URL for that representation in the Location field;
>    user agents MAY use the Location field value for automatic redirection.
>    This response is cachable unless indicated otherwise.
>
>So, please explain why you are sending a 3xx class response without a
>Location header.

I'm sending it if the server DOES NOT have a preferred choice of
representation.

Suppose I have a 5 minute movie in 3 different file formats.  Then I
don't want to have user agents not capable of transparent content
negotiation automatically retrieve one movie file.  I want to show a
HTML list to the user.

>> I have done some checking, and it seems that the creation of a new
>> response code:
>> 
>>   416 List Response
>> 
>> is the best way to get downwards compatibility.
>
>And is out of the question.  Bugwards compatibility is achieved by
>looking at the User-Agent value,  and sending 406 (or just 200 with
>an appropriate Vary and Alternates) is better than generating a
>success message masked as a client error.

OK, you don't like 416.  But I'd rather be compatible without
user-agent tricks, because user-agent tricks increase the cost of
minimal implementations and make caching *much* more difficult.

Under the current spec, an origin server can specify conditions under
which a proxy can send a cached list response to a 1.0 user agent.
This seems to be important for efficiency and scalability, but it
depends on cached list responses having a format which all 1.0 user
agents can handle.  That is why I'm seeking an alternative for using
the 300 code.

I can think of a number of alternatives to using 416:

1) Create a 2xx class response code for list responses

2) Define a list response as `a response which has an Alternates
   header but no Content-Location header'.  This allows you to pick
   whichever status code you like, for example 302 if there is a
   preferred choice, 200 if there is no preferred choice.  Or 300 if
   you know the 

Which one do you prefer?  All could be combined with language that
allows you to send 300, but discourages it if you suspect that there
may be incompatible 1.0 clients on the other end of the cache.

> ...Roy T. Fielding

Koen.

Received on Friday, 9 August 1996 06:00:03 UTC