Re: Proposal for #486: Requiring proxies to process warn-date

Looks good to me.


On 03/09/2013, at 8:08 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> ...proposed change (<trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/486/486.diff>):
> 
>     Warning       = 1#warning-value
> 
>     warning-value = warn-code SP warn-agent SP warn-text
>                                             SP warn-date
> 
>     warn-code  = 3DIGIT
>     warn-agent = ( uri-host [ ":" port ] ) / pseudonym
>                     ; the name or pseudonym of the server adding
>                     ; the Warning header field, for use in debugging
>     warn-text  = quoted-string
>     warn-date  = DQUOTE HTTP-date DQUOTE
> 
> ...
> 
>   o  1xx Warnings describe the freshness or validation status of the
>      response, and so MUST be deleted by a cache after validation.
>      They can only be generated by a cache when validating a cached
>      entry, and MUST NOT be generated in any other situation.
> 
>   o  2xx Warnings describe some aspect of the representation that is
>      not rectified by a validation (for example, a lossy compression of
>      the representation) and MUST NOT be deleted by a cache after
>      validation, unless a full response is sent, in which case they
>      MUST be.
> 
>   HTTP/1.0 caches will cache all Warnings in responses, without
>   deleting the ones in the first category.  Thus, Warnings in responses
>   carry a warning-date field, which can help in detecting an
>   erroneously cached Warning.
> 
>   RFC 2616 made the Warning header field's warn-date component
>   optional; it was only required to be sent when the recipient's
>   version was HTTP/1.0 or lower.  However, deployment experience has
>   shown that many intermediaries do not process the Warning header
>   field as required by RFC 2616.  This results in situations where the
>   field can appear in messages where it is not applicable, because a
>   warning-value has not been removed by an intermediary.
> 
>   As a result, this specification shifts responsibility for processing
>   of Warning from intermediaries to the recipient that is actually
>   consuming them.
> 
>   Generators of Warning header fields MUST include in every warning-
>   value a warn-date that matches the Date header field in the message.
>   Recipients that process a Warning header field MUST ignore (and MAY
>   remove before forwarding) a warning-value whose warn-date is
>   different from the Date value in the response.
> 
>   The following warn-codes are defined by this specification, each with
>   a recommended warn-text in English, and a description of its meaning.
> 
> ... and in the appendix:
> 
>   Some requirements regarding production of the Warning header fields
>   have been relaxed, as it is not widely implemented.  Furthermore,
>   presence of the warn-date component has been made required (dropping
>   requirements specific to HTTP/1.0).  Finally, the Warning header
>   field no longer uses RFC 2047 encoding, nor allows multiple
>   languages, as these aspects were not implemented.  (Section 7.5)
> 
> 
> Best regards, Julian

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

Received on Wednesday, 4 September 2013 04:08:17 UTC