W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [xhr] statusText is underdefined

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 27 Mar 2012 16:35:17 -0600
Message-ID: <CACQ=j+dnBLNc34K1KuNZN0gWHuZLwPi1awx_9xdQH2QkVNWZQg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 3/27/12 2:46 PM, Glenn Adams wrote:
>> Is this really a problem?
> Yes.  We've run into bug reports in the past of sites sending some pretty
> random bytes in the HTTP status text, then reading .statusText from script.
>  If we want interop here, we need to define the conversion.
>  HTTP defines the form and encoding of the status text
> Except it doesn't, last I checked.  Has that changed?

RFC2616 states (on pages :

Fielding, et al. Standards Track [Page 39]

   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Fielding, et al. Standards Track [Page 40]

   Reason-Phrase  = *<TEXT, excluding CR, LF>

Fielding, et al. Standards Track [Page 15]

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of RFC 2047

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

This makes it pretty clear that Reason Phrase must use ISO-8859-1 (Latin1)
unless it uses the encoded-word extension from RFC2047. If the latter is
used, then a charset must be designated.

Given this, I don't see any spec bug (though there may be implementation
bugs in case the client side does not correctly implement the above HTTP
Received on Tuesday, 27 March 2012 22:36:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:32 UTC