W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i74: Encoding for non-ASCII headers

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 18 Mar 2008 16:36:08 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1205854568.18425.110.camel@HenrikLaptop>

On Tue, 2008-03-18 at 09:41 +1100, Mark Nottingham wrote:
> <My inclination is that they're protocol elements, and not user- 
> visible, therefore the conservative thing to do is just document  
> current practice -- i.e., encoding isn't supported. I could see an  
> argument for explicitly saying that RFC2047 does apply there, but  
> anything beyond that seems a stretch.

Both Reason Phrase and Warning-text is indended for the human and not
automata, but it's optional to actually display them.

 The Status-Code is intended
   for use by automata and the Reason-Phrase is intended for the human
   user. The client is not required to examine or display the Reason-
   Phrase.

   Warnings also carry a warning text. The text MAY be in any
   appropriate natural language (perhaps based on the client's Accept
   headers), and include an OPTIONAL indication of what character set is
   used.

   Multiple warnings MAY be attached to a response (either by the origin
   server or by a cache), including multiple warnings with the same code
   number. For example, a server might provide the same warning with
   texts in both English and Basque.


It escapes me however however how character set indication is supposed
to be done in warning texts as it's a quoted-string.. not token|
quoted-string.

Regards
Henrik
Received on Tuesday, 18 March 2008 15:37:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT