LC comments.

Hi,
Here are a few issues/questions about [1]:

General tone of the spec seems targeted at implementors, rather than authors.
It would be more readable to have one part dedicated to users, and one part
dedicated to implementors.

In 4:
*
<<<
If stored method case-insensitively matches CONNECT, DELETE, GET, HEAD, 
OPTIONS POST, PUT, TRACE, or TRACK let stored method be the canonical 
uppercase form of the matched method name.
>>
TRACK ??? Where is the reference to that?

*
<<
14: If the user argument was not omitted and is not null let stored user 
be user encoded using the encoding specified in the relevant 
authentication scheme or UTF-8 if the scheme fails to specify an encoding.
>>
(and same for point 17)

from rfc2617:
    To receive authorization, the client sends the userid and password,
    separated by a single colon (":") character, within a base64 [7]
    encoded string in the credentials.

       basic-credentials = base64-user-pass
       base64-user-pass  = <base64 [4] encoding of user-pass,
       user-pass   = userid ":" password
       userid      = *<TEXT excluding ":">
       password    = *TEXT

    Userids might be case sensitive.

and from rfc2616:
    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
    [14].

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

So UTF8 is not the encoding of choice, there.

*
<<
For security reasons, these steps should be terminated if the header 
argument case-insensitively matches one of the following headers:

     * Accept-Charset
     * Accept-Encoding
     * Connection
     * Content-Length
     * Content-Transfer-Encoding
     * Date
     * Expect
     * Host
     * Keep-Alive
     * Referer
     * TE
     * Trailer
     * Transfer-Encoding
     * Upgrade
     * Via 
>>
What is the rationale to add headers and not others ?
Connection ?
Accept-Charset ? 
For Host, Content-Length, TE... this should be set by the implementation 
anyway, overriding what a user might fill in, so why terminate the 
processing here ?

*
<<
Also for security reasons, these steps should be terminated if the start 
of the header argument case-insensitively matches Proxy- or Sec-.
>>
It would forbid other spec to do something fancy with Proxy-* or Sec-* 
headers, why ?

* in send()
<<
If the redirect does not violate security (it is same-origin for instance) 
or infinite loop precautions and the scheme is supported transparently 
follow the redirect and go to the start of this step (step 8).

HTTP places requirements on the user agent regarding the preservation of 
the request method and entity body during redirects, and also requires 
users to be notified of certain kinds of automatic redirections.
>>
Why not linking to those requirements ?

*
<<
In case of DNS errors, or other type of network errors, run the following set of steps. This does not include HTTP responses that indicate some type of error, such as HTTP status code 410.
[...]
>>
Some request may be retried, like GET, especially if the targeted web site 
resolves in a set of IP addresses and some of them may be down. It is 
unclear that the implementation will try its best to process the request, 
by retrying when needed, or if it is forbidden.

Cheers,

[1] http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/

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

         ~~Yves

Received on Wednesday, 4 June 2008 15:45:46 UTC