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

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Aug 2009 15:49:17 +0200

Mark Nottingham wrote:
> Tracking in <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/187>

We have discussed this face-to-face last week, and I think there was 
agreement that RFC 2047 in Warning headers is not implemented anywhere, 
and thus we should remove it from the spec.

I have attached a proposed patch to the ticket, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/187/187.diff>.

The changed parts would read:

---

3.6.  Warning

    ...

    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.  If
    it is not possible to inform the user of all of the warnings, the
    user agent SHOULD follow the rule below:

    o  Warnings that appear early in the response take priority over
       those appearing later 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:

    ...

    The warn-text SHOULD be in a natural language that is most likely to
    be intelligible to the human user receiving the response.  This
    decision can be based on any available knowledge, such as the
    location of the cache or user, the Accept-Language field in a
    request, the Content-Language field in a response, etc.  The default
    language is English.

    ...

---

That being said: considering the current state of implementation support 
for Warning we may want to trim down the description even more.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 05 Aug 2009 18:56:37 +0200

> and thus we should remove it from the spec.

Not implemented anywhere, and further that if useragents actually start
displaying the warnings then they will most likely display their own
explanations in the users locale based on the error number, with the
error message more of a diagnostic message on the same level as the
reason phrase in the status line.

>     request, the Content-Language field in a response, etc.  The default

I would even go as far as drop the language reference, using text
similar to what we have for Reason-Phrase:

        The warn-text is intended to give a short textual description of
        the warn-code. The warn-code is intended for use by automata and
        the warn-text is intended for the human user. The client is not
        required to examine the warn-text.

Regards
Henrik

---

From: Yves Lafon <[email-masked]>
Date: Wed, 5 Aug 2009 13:19:13 -0400 (EDT)

>        required to examine the warn-text.

I agree, warnings are more useful for machines than humans in any case, 
and it is far better to leave the explanation of the return code to the UI 
instead of hammering something useful in a few characters.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2009 11:20:21 -0700

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

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Aug 2009 21:31:41 +0200

Mark Nottingham wrote:
> implementation of Warning in UAs. However, since as far as we know there 
> isn't, it seems reasonable.
> ...

Ack.

I have removed more text, proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/187/187.2.diff>.

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

    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.

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

    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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Aug 2009 07:55:29 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/187/187.2.diff>. 

I have applied the proposed patch with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/669>.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Aug 2009 13:52:36 +1200

Absent any pushback on this, closing #187.

On 07/08/2009, at 5:55 PM, Julian Reschke wrote:

> Julian Reschke wrote:
>> 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 have removed more text, proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/187/187.2.diff 
>> >. ...
>
> I have applied the proposed patch with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/669 
> >.
>
> BR, Julian