W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Comments on draft-ietf-http-negotiation-00.txt

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 18 Feb 1997 19:18:31 +0100 (MET)
Message-Id: <199702181818.TAA22920@wsooti06.win.tue.nl>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: cuckoo.hpl.hp.com@http-wg.uucp

>In message <Pine.SUN.3.95.970217175449.6072C-100000@xochi.tezcat.com>,
>Klaus Weide writes:
>>10.2, in description of the algorithm:
>>--- begin excerpt ---
>>     3. Check for an origin server configuration error. If the HTTP
>>        response message generated in step 2 contains an Alternates
>>        header, a Content-Location header, or has the 300 status code,
>>                  ^^^^^^^^^^^^^^^^
>>        then the best variant resource is not a proper end point in
>>        the negotiation process, and a 506 (Variant Also Negotiates)
>>        error response message should be generated instead of going to
>>        step 4.
>>--- end excerpt ---
>>
>>This seems slightly too restrictive.  Suggestion: change to "[...],
>>a non-matching Content-Location header, [...]", and add:
[...]

What about this: the check for a content-location header is removed, and in
step 4a which adds a content-location header, I add a note that the added
content location header must overwrite any content-location header already
present.

>>Reason: RFC 2068 describes several uses of Content-Location outside of
>>content negotiation (even with a SHOULD in 14.15).

The SHOULD in 14.5 is exactly why step 4a adds a content-location header.

>>  Use of this header
>>should not be discouraged by the negotiation draft

Well, the algorithm always add a content-location header, so this is not
really diminishing use.  I added the check to make it easier for service
authors to find out about configuration inconsistencies in the server.  But I
guess you are right that the current wording is too restrictive.

Roy T. Fielding:
>
>I'll second this.  Further, I'd say that there is no condition under
>which a 5xx response is justified.

Say again?  If there is no condition, why have a 5xx code at all?  The 1.1
spec says:

   Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request.

So I think a server being aware of an internal configuration error qualifies
for sending a 5xx.

>  If the response looks bad for TCN,
>then disable TCN for that response and flush your cache.

Or are you saying that a proxy cache running this algorithm may never return
a 5xx?  The 504 code seems to contradict that.


Koen.
Received on Tuesday, 18 February 1997 14:10:45 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:29 EDT