W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Issue 187 (Warn header (P6) vs RFC2047 encoding)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 05 Aug 2009 21:31:41 +0200
Message-ID: <4A79DE1D.5070707@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> +1. Talking about languages when the charset is constrained -- as well 
> as when it's not intended for end-user interpretation -- makes no sense.
> I'd be more reticent to take this path, BTW, if there were any 
> implementation of Warning in UAs. However, since as far as we know there 
> isn't, it seems reasonable.
> ...


I have removed more text, proposed patch: 

That would make the whole section read:

3.6.  Warning

    The general-header field "Warning" is used to carry additional
    information about the status or transformation of a message that
    might not be reflected in the message.  This information is typically
    used to warn about possible incorrectness introduced by caching
    operations or transformations applied to the entity body of the

    Warnings can be used for other purposes, both cache-related and
    otherwise.  The use of a warning, rather than an error status code,
    distinguish these responses from true failures.

    Warning headers can in general be applied to any message, however
    some warn-codes are specific to caches and can only be applied to
    response messages.

      Warning    = "Warning" ":" OWS Warning-v
      Warning-v  = 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, for use in debugging
      warn-text  = quoted-string
      warn-date  = DQUOTE HTTP-date DQUOTE

    Multiple warnings can be attached to a response (either by the origin
    server or by a cache), including multiple warnings with the same code
    number, only differing in warn-text.

    When this occurs, the user agent SHOULD inform the user of as many of
    them as possible, in the order that they appear in the response.

    Systems that generate multiple Warning headers SHOULD order them with
    this user agent behavior in mind.  New Warning headers SHOULD be
    added after any existing Warning headers.

    Warnings are assigned three digit warn-codes.  The first digit
    indicates whether the Warning is required to be deleted from a stored
    response after validation:

    o  1xx Warnings that describe the freshness or validation status of
       the response, and so MUST be deleted by caches after validation.
       They MUST NOT be generated by a cache except when validating a
       cached entry, and MUST NOT be generated by clients.

    o  2xx Warnings that describe some aspect of the entity body or
       entity headers that is not rectified by a validation (for example,
       a lossy compression of the entity bodies) and MUST NOT be deleted
       by caches after validation, unless a full response is returned, in
       which case they MUST be.

    If an implementation sends a message with one or more Warning headers
    to a receiver whose version is HTTP/1.0 or lower, then the sender
    MUST include in each warning-value a warn-date that matches the Date
    header in the message.

    If an implementation receives a message with a warning-value that
    includes a warn-date, and that warn-date is different from the Date
    value in the response, then that warning-value MUST be deleted from
    the message before storing, forwarding, or using it. (preventing the
    consequences of naive caching of Warning header fields.)  If all of
    the warning-values are deleted for this reason, the Warning header
    MUST be deleted as well.

    The following warn-codes are defined by this specification, each with
    a recommended warn-text in English, and a description of its meaning.

    110 Response is stale

       SHOULD be included whenever the returned response is stale.

    111 Revalidation failed

       SHOULD be included if a cache returns a stale response because an
       attempt to validate the response failed, due to an inability to
       reach the server.

    112 Disconnected operation

       SHOULD be included if the cache is intentionally disconnected from
       the rest of the network for a period of time.

    113 Heuristic expiration

       SHOULD be included if the cache heuristically chose a freshness
       lifetime greater than 24 hours and the response's age is greater
       than 24 hours.

    199 Miscellaneous warning

       The warning text can include arbitrary information to be presented
       to a human user, or logged.  A system receiving this warning MUST
       NOT take any automated action, besides presenting the warning to
       the user.

    214 Transformation applied

       MUST be added by an intermediate cache or proxy if it applies any
       transformation changing the content-coding (as specified in the
       Content-Encoding header) or media-type (as specified in the
       Content-Type header) of the response, or the entity-body of the
       response, unless this Warning code already appears in the

    299 Miscellaneous persistent warning

       The warning text can include arbitrary information to be presented
       to a human user, or logged.  A system receiving this warning MUST
       NOT take any automated action.

BR, Julian
Received on Wednesday, 5 August 2009 19:32:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC