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

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

Received on Tuesday, 3 September 2013 10:09:20 UTC