- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 13 Jul 2009 15:41:06 +1000
- To: Paul Leach <paulle@windows.microsoft.com>
- Cc: "Travis Snoozy (Volt)" <a-travis@microsoft.com>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, <ietf-http-wg@w3.org>
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/
Received on Monday, 13 July 2009 05:42:20 UTC