Re: LC comments.

On Thu, 12 Jun 2008, Anne van Kesteren wrote:

> Note: confusingly enough our mailing list changed names. I cc'ed the new 
> list.

Thanks, I was not subscribed to the previous one anyway :)

> On Wed, 04 Jun 2008 17:45:11 +0200, Yves Lafon <ylafon@w3.org> wrote:
>> 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.
>
> The WG might issue a primer document aimed at authors at some later stage.

Well, having two documents would be even more confusing; Giving in the 
first part of the document everything needed for authors (including parts 
of "how it works under the hood" for those interested), and a second part 
about all implementations requirements needed for interop would be a huge 
win for authors.

>> <<<
>> 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?
>
> Just see it as a magical string the user agent has to reject. A note has been 
> added to clarify why it is mentioned:
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest/#open

Well, magic is quite scary, I'd rather have a statement explaining roughly 
what TRACK is about (something non standard, not well documented, and 
quite similar in functionnality to TRACE).

>> <<
>> 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.
>>>> 
>> [...]
>> 
>> So UTF8 is not the encoding of choice, there.
>
> UTF-8 was a final fallback. Anyway, this has been removed leaving it up to 
> the authentication schemes to define this properly.

Thanks.

>> <<
>> 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 ?
>
> These are headers better controlled by user agents. All others can set by the 
> author. The specification is now more detailed on this:
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest/#setrequestheader
>

Ok, it certainly clarifies things.


>> <<
>> 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 ?
>
> This allows the introduction of headers in the future that can't be set by 
> XMLHttpRequest.

Yes, but 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 ?
>
> Because HTTP is to be fully read and understood anyway when implementing 
> XMLHttpRequest.

Then you don't need to restate what is already in rfc2616 and can 
completely remove the last paragraph (but you know it will be dangerous 
for interop, as most people won't read the whole tree of linked documents)
At least a link would help people find those requirements, no extra text 
needed.

>> *
>> <<
>> 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.
>
> In case it is not an error it should just do what HTTP specifies.

Well, that's not how I read the list here. I see "try to connect, if it 
fails -> exit in error".
Cheers,

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

         ~~Yves

Received on Friday, 13 June 2008 09:23:03 UTC