W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: LC comments.

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 12 Jun 2008 13:53:02 +0200
To: "Yves Lafon" <ylafon@w3.org>
Cc: public-webapps@w3.org
Message-ID: <op.ucmwmonl64w2qv@annevk-t60.oslo.opera.com>

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

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.


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


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


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


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


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


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


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Thursday, 12 June 2008 11:53:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:25 GMT