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

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/

Received on Monday, 1 January 2007 01:07:17 UTC