Subject: Re: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

From: Mark Nottingham <[email-masked]>
Date: Mon, 1 Jan 2007 12:07:04 +1100

Added as i54;
   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/index.html#i54

On 2006/12/23, at 8:54 AM, Travis Snoozy (Volt) wrote:

>
> (Supporting references at the end of the message)
>
> The offending part of section 13.1.2 (Warnings, page 77) reads:
>
>    [...]
>
>    1xx  Warnings that describe the freshness or revalidation status of
>      the response, and so MUST be deleted after a successful
>      revalidation. 1XX [sic] warn-codes MAY be generated by a cache  
> only
>      when validating a cached entry. It MUST NOT be generated by  
> clients.
>
>    [...]
>
>
> The problems, in order from simplest to the most complex:
>
> 1. 1XX should be 1xx (or vice-versa) everywhere.
>
> Proposed fix: pick one, and use it everywhere. I'm partial to 1xx  
> myself :).
>
>
> 2. The use of MAY in the offending part of 13.1.2 conflicts with  
> the MUST
>    requirements in section 14.46 and the definition of MAY in BCP14.
>
> Proposed fix: "1xx warn-codes MUST NOT be added to any messages  
> except cache
> entries, and MUST NOT be added to cache entries except in response  
> to a
> validation attempt." (As a side note, a definition of a cache entry  
> would be
> nice.)
>
>
> 3. One would think that proxies could include caches (though I have  
> yet to
>    find where this is permitted with a true BCP14 MAY). However,  
> the wording
>    in the offending part of 13.1.2 makes it impossible to satisfy the
>    requirements of a cache and the requirements of a client (and, by
>    extension, proxy) simultaneously. A cache is not an independent  
> program;
>    it is part of a program (as per the 1.3 definition). A client is a
>    program, and it can contain a cache (again, from 1.3), but this  
> limits
>    the cache's behavior to the set intersection of allowed  
> behaviors for
>    caches and clients (due to how "client" is defined). This leads  
> to a
>    conflict where the cache MUST generate a 1xx code, but a client  
> MUST NOT
>    generate a 1xx code. Thus, we're left having to conclude that  
> caches can
>    exist only as part of independent servers (which have their content
>    pushed to them, or delivered through some out-of-band method).
>
> Proposed fix: Maybe "Clients that do not incorporate a cache MUST NOT
> generate 1xx warn-codes", but I'm not sure what problem the  
> original clause
> was trying to prevent. The proposed fix in (2) above might cover  
> everything, allowing the deletion of this sentence altogether.
>
>
> -- Travis
>
> --- Supporting References ---
>
> Section 14.46 (Warning, page 149) reads:
>
>    [...]
>
>    110 Response is stale
>      MUST be included whenever the returned response is stale.
>
>    111 Revalidation failed
>      MUST be included if a cache returns a stale response because an
>      attempt to revalidate the response failed, due to an inability to
>      reach the server.
>
>    [...]
>
>    113 Heuristic expiration
>      MUST be included if the cache heuristically chose a freshness
>      lifetime greater than 24 hours and the response's age is greater
>      than 24 hours.
>
>    [...]
>
> Some definitions from section 1.3 (Terminology, pages 9-10):
>
>    [...]
>
>    client
>       A program that establishes connections for the purpose of  
> sending
>       requests.
>
>    [...]
>
>    proxy
>       An intermediary program which acts as both a server and a client
>       for the purpose of making requests on behalf of other  
> clients. [...]
>       A proxy MUST implement both the client and server  
> requirements of this
>       specification. [...]
>
>    cache
>       A program's local store of response messages and the subsystem
>       that controls its message storage, retrieval, and deletion. A
>       cache stores cacheable responses in order to reduce the response
>       time and network bandwidth consumption on future, equivalent
>       requests. Any client or server may include a cache, though a  
> cache
>       cannot be used by a server that is acting as a tunnel.
>
>    [...]
>

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

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 2 Jan 2007 11:01:51 -0800

>    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."

Thanks,

-- Travis

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Tue, 02 Jan 2007 13:43:16 -0600

> 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.

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 2 Jan 2007 12:27:19 -0800

William A. Rowe, Jr. said:
> > 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."
>

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

---

From: Paul Leach <[email-masked]>
Date: Tue, 2 Jan 2007 12:51:28 -0800

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Travis Snoozy (Volt)
Sent: Tuesday, January 02, 2007 12:27 PM
To: William A. Rowe, Jr.
Cc: Mark Nottingham; [email-masked]
Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

William A. Rowe, Jr. said:
> > The modified proposal (after discussion) is as follows (should fix
all
> three problems mentioned):
> >

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.

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

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 2 Jan 2007 13:08:55 -0800

Paul Leach said:
> If a client implements a cache, then it's a cache,

... but that does not stop it from being a client, and clients and caches have conflicting requirements (see previous messages in this thread) ...

> and it's the server side of the cache that adds the warn-code to the
> response.

Close, but no cigar. See section 1.3 (definitions of "cache," "proxy," and
"client") and my prior messages in this thread. There is no "server side" to
a cache, nor is there a "client side" to it -- at least, not defined by the
spec (implementation-wise there might be). A client that implements a cache
is not automatically a server, and a server that implements a cache is not
necessarily a client (though at first glance it might appear to have to be).
Note that it has to be this way, because if a cache had a "server" bit and a
"client" bit, there would be a circular reference (both the server and
client bits could implement a cache, which in turn would have their own
client/server bits, and so on down).

FWIW, your wording is more or less the terminology I used in my annotation
on how to interpret this clause; however, it's not a real solution to the
direct problem this clause is posing (i.e., bad phrasing and not saying what
it really means).

<snip>

Thanks,

-- Travis

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 2 Jan 2007 13:23:51 -0800

> The modified proposal (after discussion) is ...
> "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."

I think this rewrite is worse than the text it
proposes to replace, as far as being misleading.
The text is part of a description of the differences
between 1xx warnings and 2xx warnings, and the
'right' rewrite is to make the descriptions more
parallel.

The actual conditions for when a 1xx warning 
may be generated (and MUST NOT) be generated
are contained in section 13.1.1. 

Probably the right thing to do is to tighten up the
language in 13.1.1 so that it is clearly normative,
and then chanage the 3.1.2 Warnings section so that
it doesn't attempt to summarize them more succinctly
than they can be. I'd suggest:

   1xx  Warnings that describe the freshness or revalidation status of
     the response. These warnings are generally deleted after
     successful validation (the rules for when a cache MUST or
     MUST NOT include or delete a warning response are in section 13.1.1.)

   2xx  Warnings that describe some aspect of the entity body or entity
     headers that is not rectified by a revalidation (for example, a
     lossy compression of the entity bodies). 2xx MUST NOT be
     deleted after a successful revalidation.

---

From: Paul Leach <[email-masked]>
Date: Tue, 2 Jan 2007 13:46:19 -0800

You're right -- I said "cache" when I was thinking "caching proxy".

-----Original Message-----
From: Travis Snoozy (Volt) 
Sent: Tuesday, January 02, 2007 1:09 PM
To: Paul Leach; William A. Rowe, Jr.
Cc: Mark Nottingham; [email-masked]
Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

> If a client implements a cache, then it's a cache,

... but that does not stop it from being a client, and clients and
caches have conflicting requirements (see previous messages in this
thread) ...

> and it's the server side of the cache that adds the warn-code to the

Close, but no cigar. See section 1.3 (definitions of "cache," "proxy,"
and 
"client") and my prior messages in this thread. There is no "server
side" to 
a cache, nor is there a "client side" to it -- at least, not defined by
the 
spec (implementation-wise there might be). A client that implements a
cache
is not automatically a server, and a server that implements a cache is
not 
necessarily a client (though at first glance it might appear to have to
be).
Note that it has to be this way, because if a cache had a "server" bit
and a 
"client" bit, there would be a circular reference (both the server and 
client bits could implement a cache, which in turn would have their own 
client/server bits, and so on down).

FWIW, your wording is more or less the terminology I used in my
annotation 
on how to interpret this clause; however, it's not a real solution to
the 
direct problem this clause is posing (i.e., bad phrasing and not saying
what 
it really means).

<snip>

Thanks,

-- Travis

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 2 Jan 2007 13:48:36 -0800

> are contained in section 13.1.1.

13.1.1 specifies when Warning headers need to be generated; it defers to
14.46 when it comes to the actual warn-codes that need to be included.

>      deleted after a successful revalidation.

Works for me, but I'd move "the rules for when a cache MUST or MUST NOT..."
bit to precede the table (since it applies to both 1xx and 2xx codes), OR
make it explicitly reference 1xx warn-codes and section 14.46 (since 3.1.1
does not actually talk about 1xx warn-codes at all).

Thanks,

-- Travis

---

From: "Mike Whitehurst" <[email-masked]>
Date: Tue, 2 Jan 2007 22:17:15 -0000

anyone know why i'm unable to unsubscribe from this group?

----- Original Message ----- 
From: "Travis Snoozy (Volt)" <[email-masked]>
To: "Larry Masinter" <[email-masked]>; "'Mark Nottingham'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 02, 2007 9:48 PM
Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

Thanks,

-- Travis

---

From: Paul Leach <[email-masked]>
Date: Tue, 2 Jan 2007 14:19:29 -0800

I'd also point out that 14.46 doesn't seem to make the same distinction
about deleting 1xx warn-codes and not deleting 2xx warn-codes -- it
seems to treat them pretty much the same. To wit, from 14.46:

"However, if a cache successfully validates a cache entry, it SHOULD
remove any Warning headers previously attached to that entry except as
specified for specific Warning codes." 

No distinction between 1xx and 2xx. 

There's an awful lot of redundancy between 13.1.1-2 and 14.46.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Travis Snoozy (Volt)
Sent: Tuesday, January 02, 2007 1:49 PM
To: Larry Masinter; 'Mark Nottingham'
Cc: [email-masked]
Subject: RE: NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

>      deleted after a successful revalidation.

Works for me, but I'd move "the rules for when a cache MUST or MUST
NOT..."
bit to precede the table (since it applies to both 1xx and 2xx codes),
OR
make it explicitly reference 1xx warn-codes and section 14.46 (since
3.1.1
does not actually talk about 1xx warn-codes at all).

Thanks,

-- Travis

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Tue, 2 Jan 2007 14:43:07 -0800

Paul Leach said:
> about deleting 1xx warn-codes and not deleting 2xx warn-codes -- it seems
> to treat them pretty much the same. To wit, from 14.46:
>

14.46 back-references to 13.1.2 (page 149):

"Requirements for the behavior of caches with respect to Warnings are stated
in section 13.1.2."

And 13.1.2 *does* distinguish between the cases, but I'm not immediately
convinced that it does so in a way that's compatible with the SHOULD clause
you reproduced above. It seems like a similar issue between the 13.1.2 MAY
and the 14.46 MUSTs.

> There's an awful lot of redundancy between 13.1.1-2 and 14.46.

I'd agree that there seems to be a lot of redundancy; all these different
locations seem to be trying to specify the same thing, or at least parts of
the same thing with overlap in between. But, how should we go about fixing
it?

<snip>

Thanks,

-- Travis

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Jan 2007 19:47:20 +1100

Take a look at:
   http://www.w3.org/Mail/Request

If you still have problems, ping me and I'll work with the  
appropriate W3C folks.

Cheers,

On 2007/01/03, at 9:17 AM, Mike Whitehurst wrote:

> ----- Original Message ----- From: "Travis Snoozy (Volt)" <a- 
> [email-masked]>