Re: [#54] 13.1.2's Definition of 1xx Warn-Codes

I haven't seen any response to this, so either people agree, or people  
aren't inclined to put much more effort into something that isn't  
widely implemented.

Regardless, I'll schedule for -08 and we'll see if it sticks.


On 13/07/2009, at 3:41 PM, Mark Nottingham wrote:

> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/54
>
> Parts 1 and 2 of this issue were taken care of in the -06 revision.  
> Part 3 is still present, in this text:
>> They MUST NOT be generated by a cache except when validating a  
>> cached entry, and MUST NOT be generated by clients.
>
> I think we can resolve this by replacing the text above with:
>
> They can only be generated by a cache that is validated a stored  
> entry, and MUST NOT be generated in any other situation.
>
> It's also probably worth putting in a reference to this from 2.4  
> Validation Model.
>
> Thoughts?
>
>
>
> On 03/01/2007, at 7:51 AM, Paul Leach wrote:
>
>> If a client implements a cache, then it's a cache, and it's the  
>> server
>> side of the cache that adds the warn-code to the response.
>>
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg- 
>> request@w3.org]
>> On Behalf Of Travis Snoozy (Volt)
>> Sent: Tuesday, January 02, 2007 12:27 PM
>> To: William A. Rowe, Jr.
>> Cc: Mark Nottingham; ietf-http-wg@w3.org
>> Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes
>>
>>
>> William A. Rowe, Jr. said:
>>> Travis Snoozy (Volt) wrote:
>>>> Mark Nottingham said:
>>>>> Added as i54;
>>>>>
>>> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ 
>>> index.html#i54
>>>>>
>>>> <snip>
>>>>
>>>> The modified proposal (after discussion) is as follows (should fix
>> all
>>> three problems mentioned):
>>>>
>>>> "A cache MUST NOT generate 1xx warn-codes for any messages except
>> cache
>>>> entries, and MUST NOT generate 1xx warn-codes for a cache entry
>> except
>>>> in response to a validation attempt for that entry. 1xx warn-codes
>> MUST
>>>> NOT be generated in Request messages."
>>>
>>> Explain again how any code is passed as a Request message?  The
>> original
>>> language, "MUST NOT be generated by Clients" was correct.
>>
>> To answer your question:
>>
>> 2xx warn-codes could be added to a Request, e.g., by a proxy that is
>> transforming requests between the user-agent and the origin server.  
>> This
>> is
>> perfectly valid, and desirable, though likely uncommon.
>>
>> To the original language is incorrect:
>>
>> Clients should be allowed to generate 1xx warn-codes in Responses  
>> -- all
>> the
>> client has to do is implement a cache, and the client will need the
>> ability
>> to add 1xx warn-codes to its cached Responses. Thus, the original
>> language
>> ("1XX warn-codes MAY be generated by a cache only when validating a
>> cached
>> entry. It MUST NOT be generated by clients.") is incorrect, unless  
>> the
>> intent is to effectively prohibit clients (including proxies) from
>> implementing a cache. Such a prohibition, given the context of the  
>> rest
>> of
>> the spec, is so silly as to be laughable; thus, the wording here  
>> needs
>> to be
>> corrected.
>>
>> The proposed wording means that clients (and everything else) MUST  
>> NOT
>> generate 1xx warn-codes in Request messages (because it's nonsense).
>> Clients
>> (and everything else) can generate 1xx warn-codes in Response  
>> messages,
>> though cache subsystems (in clients or otherwise) have some extra  
>> rules
>> to
>> follow. There's no reason to have a blanket prohibition on clients
>> generating 1xx warn-codes in Responses.
>>
>> On further reflection, there is an issue that I have with the above
>> proposed
>> wording: the context might imply that "1xx warn-codes MUST NOT be
>> generated
>> in Request messages" _by caches_, instead of by anything.
>>
>>
>> Thanks,
>>
>> -- Travis
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 6 October 2009 05:33:40 UTC