httpbis: Ticket #54: Definition of 1xx Warn-Codes
Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/54
Origin:
http://www.w3.org/mid/86EDC3963F04D546BED8996F77D290F6049D117A9F@NA-EXMSG-C138.redmond.corp.microsoft.com
Component:
p6-cache
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:
- 1XX should be 1xx (or vice-versa) everywhere.
- 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.
- 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).
Mails
History
: comment added (Sat, 22 Dec 2007 02:36:35 GMT)
Proposal:
- pick one, and use it everywhere. I'm partial to 1xx myself :).
- "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.)
- 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.
: comment added; component, milestone set (Fri, 04 Jan 2008 06:08:49 GMT)
-
component
set to cache
-
milestone
set to unassigned
Related Information
Issues List Index