W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 13 Jul 2009 15:41:06 +1000
Cc: "Travis Snoozy (Volt)" <a-travis@microsoft.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, <ietf-http-wg@w3.org>
Message-Id: <6CB7DA30-7200-4CF7-95FD-480FFC6FAB80@mnot.net>
To: Paul Leach <paulle@windows.microsoft.com>

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.


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
>>> 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/
Received on Monday, 13 July 2009 05:42:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC