Last Call - XMLHttpRequest

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Last Call - XMLHttpRequest

Charles McCathieNevile-2

Hi folks,

I am pleased to announce that the Web API group has published a Last Call Working Draft of XML HTTP Request at http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/

The Abstract and Status of the Document sections are reproduced at the end of this mail.

This draft is for public review and comment, because the working group believes that it has finished the specification. If you have review comments you would like addressed, please send them with either [XHR] or [XMLHttpRequest] at the start of the subject line to the WebAPI list ([hidden email]) by April 2, 2007.

That list is archived at http://lists.w3.org/Archives/Public/public-webapi/ 

If you need more time to send comments, please send a message saying so, and when you expect your comments to be completed. While we do not guarantee to deal with late comments we will attempt to do so.

Thanks to Anne van Kesteren who edited, and the many people who contributed to, the specification.

====
Abstract

The XMLHttpRequest Object specification defines an API that provides scripted client functionality for transferring data between a client and a server.
====
Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 27 February 2007 Last Call Working Draft of The XMLHttpRequest Object specifcation. Please send comments to [hidden email] (archived) with either [XHR] or [XMLHttpRequest] at the start of the subject line by 2 April 2007.

This document is produced by the Web API Working Group, part of the Rich Web Clients Activity in the W3C Interaction Domain. Changes made to this document can be found in the W3C public CVS server.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
====

cheers

Chaals

--
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[hidden email]          Try Opera 9.1     http://opera.com

Reply | Threaded
Open this post in threaded view
|

Re: Last Call - XMLHttpRequest

Dan Winship

Here's what I found reading through the last call draft:

> readyState...
>   3 Receiving
>       Immediately before receiving the message body (if any). All HTTP
>       headers have been received.

That description isn't quite right, since readyState is 3 *while*
receiving the message body too. Maybe:

        3 Receiving
            All HTTP headers have been received. The message body (if
        any)
            has not yet been fully received.

> a SECURITY_ERR should be raised

Where is SECURITY_ERR defined? (AFAICT the answer is "nowhere".)

> User agents MUST at least support the following list of methods (see
> [RFC2616]):
>    * GET
>    * POST
>    * HEAD
>    * PUT
>    * DELETE
>    * OPTIONS
> ...
> When method case-insensitively matches GET, POST, HEAD, PUT or
> DELETE user agents MUST use the uppercase equivalent instead.

OPTIONS got added to the first last in the most recent draft, and should
probably be added to the second list as well for consistency.

> When url is a relative reference, it MUST be resolved using the
> current value of the baseURI attribute of the Document object
> currently associated with the Window pointer and the fragment
> identifier component, if any, MUST be dropped.

Fragments MUST be dropped on relative URLs, but not on absolute URLs???

> If data is passed to the send() method it MUST be used for the
> entity body as defined by section 7.2 of [RFC2616] The following
> rules apply:

There's a period missing between "[RFC2616]" and "The". (It's also not
clear on first reading if "data is passed to send()" is intended to
contrast with "send(null)" or "send()" with no argument. "If non-null
data is passed..." would be clearer.)

> If the response is an HTTP redirect (status code 301, 302, 303 or
> 307), then it MUST be transparently followed (unless it violates
> security, infinite loop precautions or the scheme isn't supported).
>
>     Note: HTTP places requirements on user agents 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.

It's actually a stronger requirement than just notification: "the user
agent MUST NOT automatically redirect the request unless it can be
confirmed by the user". Might be better to let the implementation just
not follow the redirect in this case:

        If the response is an HTTP redirect (status code 301, 302, 303
        or 307), then it MUST be transparently followed (unless doing so
        would violate a requirement or recommendation of this
        specification or [RFC2616]).

or something.

> If something goes wrong [during send] (infinite loop, network errors)
> the state MUST be set to loaded... In addition, all registered event
> listeners MUST be removed.

> When invoked, this method [abort] MUST cancel any network activity for
> which the object is responsible and set all the members of the object
> to their initial values as well as removing all event listeners.

Does the onreadystatechange listener get invoked in these two cases? An
implementation that performed the actions in the order written (change
state first, remove event listeners last) would cause the listener to
be invoked, but nothing says that the implementation has to do it in
that order, which seems to make this implementation-defined.

> HTTP requests sent from multiple different XMLHttpRequest objects in
> succession SHOULD use a shared HTTP connection.

How does this deserve an RFC2119 "SHOULD" ("the full implications must
be understood and carefully weighed before choosing a different
course.") And why does it only talk about requests from *different* XHR
objects? What about multiple requests from the same object? If you're
going to say anything here, just say "Implementations SHOULD NOT suck"
and be done with it. ;-)

-- Dan




Reply | Threaded
Open this post in threaded view
|

[XMLHttpRequest] last call comments

Julian Reschke
In reply to this post by Charles McCathieNevile-2

Hi all,

See below my updated set of comments (some of the previously mentioned
problems have been fixed, thanks for that).

Best regards, Julian

-- snip --


Review of <http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/>.



1.2 Conformance

"conforming implementation
     A user agent must behave as described in this specification in
order to be considered conformant even when faced with non-conforming
scripts."

So is an implementation that violates a SHOULD-level requirement conforming?


2.1. Members of the XMLHttpRequest Object

"When method case-insensitively matches GET, POST, HEAD, PUT or DELETE
user agents MUST use the uppercase equivalent instead."

I know this is for compatibility with some broken implementations. I'd
prefer to leave this out, and to make them non-conforming (they are
likely to be non-conforming already). If this is to stay, the set of
affected method names should be revisited. Do they all need to be on
this list?

"The syntax for the user or password arguments depends on the scheme
being used. If the syntax for either is incorrect per the production
given in the relevant scheme user agents must throw a SYNTAX_ERR
exception. The user and password must be encoded using the encoding
specified by the scheme. If the scheme fails to specify an encoding they
must be encoded using UTF-8."

I think this has been mentioned before: does this reflect what today's
implementations do for basic and digest?

Also: s/scheme/authentication scheme/.

"Otherwise, if the header argument does not match any of the listed
headers and already has a value that value must  be retained. User
agents may either use multiple headers, combine the values or use a
combination of those (section 4.2, RFC 2616). [RFC2616]"

Why doesn't the preceding list contain other headers known not to have
that format? (c-ext, ext (RFC2774), cookie, cookie2 (RFC2965), if,
lock-token, status-uri (RFC2518), label (RFC3253),
apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)).

It seems to me that it would be wise for the specification to specify a
way to remove a header, so that list-typed headers can be set to a known
value reliably (preferably removeRequestHeader() to remove a header, and
getRequestHeader() to check the current value).

"If the response is an HTTP redirect (status code 301, 302, 303 or 307),
then it MUST be transparently followed (unless it violates security,
infinite loop precautions or the scheme isn't supported). Note that HTTP
([RFC2616]) places requirements on user agents regarding the
preservation of the request method during redirects, and also requires
users to be notified of certain kinds of automatic redirections."

To follow a redirect on a non-safe method without the user's consent is
forbidden in HTTP (see RFC2616, 10.2). No, notification is not
sufficient.  And yes, this also applies to POST.

"If the user agent supports HTTP State Mangement it should persist,
discard and send cookies (as received in the Set-Cookie and Set-Cookie2
response headers, and sent in the Cookie header) as applicable. [RFC2965]"

s/State Mangement/State Management/


My main other issue with this spec that it is silent about the
recommended behaviour for unsafe methods, about which RFC2616 says in
Section 9.1.1
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>):

"Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow the
user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD
methods SHOULD NOT have the significance of taking an action other than
retrieval. These methods ought to be considered "safe". This allows user
agents to represent other methods, such as POST, PUT and DELETE, in a
special way, so that the user is made aware of the fact that a possibly
unsafe action is being requested."

Thus, allowing a web page to submit a PUT, POST or DELETE request
without user interaction seems to be a very dangerous thing to me, and
the spec should point that out (see also
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>).



Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Bjoern Hoehrmann

* Julian Reschke wrote:
>"The syntax for the user or password arguments depends on the scheme
>being used. If the syntax for either is incorrect per the production
>given in the relevant scheme user agents must throw a SYNTAX_ERR
>exception. The user and password must be encoded using the encoding
>specified by the scheme. If the scheme fails to specify an encoding they
>must be encoded using UTF-8."
>
>I think this has been mentioned before: does this reflect what today's
>implementations do for basic and digest?

Could you be more specific? Firefox for example will mangle non-ascii
user names and passwords in strange and harmful ways, so strictly the
answer to your question is "no" but I don't see this as a problem.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Julian Reschke

Bjoern Hoehrmann schrieb:

> * Julian Reschke wrote:
>> "The syntax for the user or password arguments depends on the scheme
>> being used. If the syntax for either is incorrect per the production
>> given in the relevant scheme user agents must throw a SYNTAX_ERR
>> exception. The user and password must be encoded using the encoding
>> specified by the scheme. If the scheme fails to specify an encoding they
>> must be encoded using UTF-8."
>>
>> I think this has been mentioned before: does this reflect what today's
>> implementations do for basic and digest?
>
> Could you be more specific? Firefox for example will mangle non-ascii
> user names and passwords in strange and harmful ways, so strictly the
> answer to your question is "no" but I don't see this as a problem.

Well, we have that problem with balancing between what would be the
right thing to do, and what the user agents actually implement. I do
agree that UTF-8 would be a good choice if the authentication scheme
spec is silent about it.

That being said: does the Firefox issue have an issue reported? And how
do IE and Opera behave?

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: Re: Last Call - XMLHttpRequest

Anne van Kesteren-2
In reply to this post by Dan Winship

On Wed, 28 Feb 2007 22:54:47 +0100, Dan Winship <[hidden email]> wrote:
> That description isn't quite right, since readyState is 3 *while*
> receiving the message body too. Maybe:

Fixed.


> Where is SECURITY_ERR defined? (AFAICT the answer is "nowhere".)

It will be defined in a revision of DOM Level 3 Core.


>> User agents MUST at least support the following list of methods (see
>> [RFC2616]):
>>    * GET
>>    * POST
>>    * HEAD
>>    * PUT
>>    * DELETE
>>    * OPTIONS
>> ...
>> When method case-insensitively matches GET, POST, HEAD, PUT or
>> DELETE user agents MUST use the uppercase equivalent instead.
>
> OPTIONS got added to the first last in the most recent draft, and should
> probably be added to the second list as well for consistency.

Added.


>> When url is a relative reference, it MUST be resolved using the
>> current value of the baseURI attribute of the Document object
>> currently associated with the Window pointer and the fragment
>> identifier component, if any, MUST be dropped.
>
> Fragments MUST be dropped on relative URLs, but not on absolute URLs???

Fixed.


>> If data is passed to the send() method it MUST be used for the
>> entity body as defined by section 7.2 of [RFC2616] The following
>> rules apply:
>
> There's a period missing between "[RFC2616]" and "The". (It's also not
> clear on first reading if "data is passed to send()" is intended to
> contrast with "send(null)" or "send()" with no argument. "If non-null
> data is passed..." would be clearer.)

Fixed.


>> If the response is an HTTP redirect (status code 301, 302, 303 or
>> 307), then it MUST be transparently followed (unless it violates
>> security, infinite loop precautions or the scheme isn't supported).
>>
>>     Note: HTTP places requirements on user agents 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.
>
> It's actually a stronger requirement than just notification: "the user
> agent MUST NOT automatically redirect the request unless it can be
> confirmed by the user". Might be better to let the implementation just
> not follow the redirect in this case:
>
>         If the response is an HTTP redirect (status code 301, 302, 303
>         or 307), then it MUST be transparently followed (unless doing so
>         would violate a requirement or recommendation of this
>         specification or [RFC2616]).
>
> or something.

It's a note because it doesn't make sense to reiterate the requirements  
 from HTTP. It does clearly list, imo, that it's a requirement in HTTP.


>> If something goes wrong [during send] (infinite loop, network errors)
>> the state MUST be set to loaded... In addition, all registered event
>> listeners MUST be removed.
>
>> When invoked, this method [abort] MUST cancel any network activity for
>> which the object is responsible and set all the members of the object
>> to their initial values as well as removing all event listeners.
>
> Does the onreadystatechange listener get invoked in these two cases? An
> implementation that performed the actions in the order written (change
> state first, remove event listeners last) would cause the listener to
> be invoked, but nothing says that the implementation has to do it in
> that order, which seems to make this implementation-defined.

Fixed.


>> HTTP requests sent from multiple different XMLHttpRequest objects in
>> succession SHOULD use a shared HTTP connection.
>
> How does this deserve an RFC2119 "SHOULD" ("the full implications must
> be understood and carefully weighed before choosing a different
> course.") And why does it only talk about requests from *different* XHR
> objects? What about multiple requests from the same object? If you're
> going to say anything here, just say "Implementations SHOULD NOT suck"
> and be done with it. ;-)

Dropped based on a comment from someone else.

Cheers,


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Anne van Kesteren-2
In reply to this post by Julian Reschke

On Sun, 04 Mar 2007 20:50:13 +0100, Julian Reschke <[hidden email]>  
wrote:
> 1.2 Conformance
>
> "conforming implementation
>      A user agent must behave as described in this specification in  
> order to be considered conformant even when faced with non-conforming  
> scripts."
>
> So is an implementation that violates a SHOULD-level requirement  
> conforming?

Yes. If it has good reasons to do so. See RFC 2119.


> 2.1. Members of the XMLHttpRequest Object
>
> "When method case-insensitively matches GET, POST, HEAD, PUT or DELETE  
> user agents MUST use the uppercase equivalent instead."
>
> I know this is for compatibility with some broken implementations.

This is for compatibility with the web.


> [...] If this is to stay, the set of affected method names should be  
> revisited. Do they all need to be on this list?

Feedback indicated that they should all be in the list, yes.


> "The syntax for the user or password arguments depends on the scheme  
> being used. If the syntax for either is incorrect per the production  
> given in the relevant scheme user agents must throw a SYNTAX_ERR  
> exception. The user and password must be encoded using the encoding  
> specified by the scheme. If the scheme fails to specify an encoding they  
> must be encoded using UTF-8."
>
> I think this has been mentioned before: does this reflect what today's  
> implementations do for basic and digest?

I don't think so.


> Also: s/scheme/authentication scheme/.

Done.


> "Otherwise, if the header argument does not match any of the listed  
> headers and already has a value that value must  be retained. User  
> agents may either use multiple headers, combine the values or use a  
> combination of those (section 4.2, RFC 2616). [RFC2616]"
>
> Why doesn't the preceding list contain other headers known not to have  
> that format? (c-ext, ext (RFC2774), cookie, cookie2 (RFC2965), if,  
> lock-token, status-uri (RFC2518), label (RFC3253),  
> apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)).

I added these, but I'm not convinced this list is a good idea anymore...  
Firefox seems to always replace, Internet Explorer always merges headers.  
Only Opera seems to have the logic as described by the specification. Not  
sure about Safari. Tests are here:

   http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/


(The above mentioned headers don't appear to be supported by Opera in this  
way, fwiw.)


> It seems to me that it would be wise for the specification to specify a  
> way to remove a header, so that list-typed headers can be set to a known  
> value reliably (preferably removeRequestHeader() to remove a header, and  
> getRequestHeader() to check the current value).

I already mentioned that this will be considered for a future version.  
That hasn't changed.


> "If the response is an HTTP redirect (status code 301, 302, 303 or 307),  
> then it MUST be transparently followed (unless it violates security,  
> infinite loop precautions or the scheme isn't supported). Note that HTTP  
> ([RFC2616]) places requirements on user agents regarding the  
> preservation of the request method during redirects, and also requires  
> users to be notified of certain kinds of automatic redirections."
>
> To follow a redirect on a non-safe method without the user's consent is  
> forbidden in HTTP (see RFC2616, 10.2). No, notification is not  
> sufficient.  And yes, this also applies to POST.

What text would you like us to use instead?


> "If the user agent supports HTTP State Mangement it should persist,  
> discard and send cookies (as received in the Set-Cookie and Set-Cookie2  
> response headers, and sent in the Cookie header) as applicable.  
> [RFC2965]"
>
> s/State Mangement/State Management/

Fixed.


> My main other issue with this spec that it is silent about the  
> recommended behaviour for unsafe methods, about which RFC2616 says in  
> Section 9.1.1  
> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>):
>
> "Implementors should be aware that the software represents the user in  
> their interactions over the Internet, and should be careful to allow the  
> user to be aware of any actions they might take which may have an  
> unexpected significance to themselves or others.
>
> In particular, the convention has been established that the GET and HEAD  
> methods SHOULD NOT have the significance of taking an action other than  
> retrieval. These methods ought to be considered "safe". This allows user  
> agents to represent other methods, such as POST, PUT and DELETE, in a  
> special way, so that the user is made aware of the fact that a possibly  
> unsafe action is being requested."
>
> Thus, allowing a web page to submit a PUT, POST or DELETE request  
> without user interaction seems to be a very dangerous thing to me, and  
> the spec should point that out (see also  
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>).

I'm not sure this is much of an issue given the same-origin nature of the  
object. However, I might be mistaken...


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Julian Reschke

Anne van Kesteren schrieb:

>
> On Sun, 04 Mar 2007 20:50:13 +0100, Julian Reschke
> <[hidden email]> wrote:
>> 1.2 Conformance
>>
>> "conforming implementation
>>      A user agent must behave as described in this specification in
>> order to be considered conformant even when faced with non-conforming
>> scripts."
>>
>> So is an implementation that violates a SHOULD-level requirement
>> conforming?
>
> Yes. If it has good reasons to do so. See RFC 2119.

I do agree that this is a good rule, but as far as I can tell, you
really need to state this (this==compliant implementations must
implement all MUST-level requirements).

>> 2.1. Members of the XMLHttpRequest Object
>>
>> "When method case-insensitively matches GET, POST, HEAD, PUT or DELETE
>> user agents MUST use the uppercase equivalent instead."
>>
>> I know this is for compatibility with some broken implementations.
>
> This is for compatibility with the web.
>
>
>> [...] If this is to stay, the set of affected method names should be
>> revisited. Do they all need to be on this list?
>
> Feedback indicated that they should all be in the list, yes.

So do we have evidence of enough broken content using lowercased method
names so that this special case makes sense?

>> "The syntax for the user or password arguments depends on the scheme
>> being used. If the syntax for either is incorrect per the production
>> given in the relevant scheme user agents must throw a SYNTAX_ERR
>> exception. The user and password must be encoded using the encoding
>> specified by the scheme. If the scheme fails to specify an encoding
>> they must be encoded using UTF-8."
>>
>> I think this has been mentioned before: does this reflect what today's
>> implementations do for basic and digest?
>
> I don't think so.

Hm. I'm wondering whether we need to label those things of which we know
that they *aren't* implemented that way accordingly.

>> "Otherwise, if the header argument does not match any of the listed
>> headers and already has a value that value must  be retained. User
>> agents may either use multiple headers, combine the values or use a
>> combination of those (section 4.2, RFC 2616). [RFC2616]"
>>
>> Why doesn't the preceding list contain other headers known not to have
>> that format? (c-ext, ext (RFC2774), cookie, cookie2 (RFC2965), if,
>> lock-token, status-uri (RFC2518), label (RFC3253),
>> apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)).
>
> I added these, but I'm not convinced this list is a good idea anymore...
> Firefox seems to always replace, Internet Explorer always merges
> headers. Only Opera seems to have the logic as described by the
> specification. Not sure about Safari. Tests are here:
>
>   http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/
>
>
> (The above mentioned headers don't appear to be supported by Opera in
> this way, fwiw.)

Interesting.

If the major implementations do not do this consistently, this is IMHO a
clear indicator that we should define new methods with clear semantics
(removeHeader, getHeader, addHeader...).

>> It seems to me that it would be wise for the specification to specify
>> a way to remove a header, so that list-typed headers can be set to a
>> known value reliably (preferably removeRequestHeader() to remove a
>> header, and getRequestHeader() to check the current value).
>
> I already mentioned that this will be considered for a future version.
> That hasn't changed.

Again, the current situation is problematic because clients can not
reliably predict what will happen when they call setRequestHeader.
Either get all vendors to implement the same thing, or add new methods
and leave setRequestHeader underspecified.

>> "If the response is an HTTP redirect (status code 301, 302, 303 or
>> 307), then it MUST be transparently followed (unless it violates
>> security, infinite loop precautions or the scheme isn't supported).
>> Note that HTTP ([RFC2616]) places requirements on user agents
>> regarding the preservation of the request method during redirects, and
>> also requires users to be notified of certain kinds of automatic
>> redirections."
>>
>> To follow a redirect on a non-safe method without the user's consent
>> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not
>> sufficient.  And yes, this also applies to POST.
>
> What text would you like us to use instead?

s/MUST/SHOULD/

Also state that this only applies to safe methods.

>> My main other issue with this spec that it is silent about the
>> recommended behaviour for unsafe methods, about which RFC2616 says in
>> Section 9.1.1
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>):
>>
>> "Implementors should be aware that the software represents the user in
>> their interactions over the Internet, and should be careful to allow
>> the user to be aware of any actions they might take which may have an
>> unexpected significance to themselves or others.
>>
>> In particular, the convention has been established that the GET and
>> HEAD methods SHOULD NOT have the significance of taking an action
>> other than retrieval. These methods ought to be considered "safe".
>> This allows user agents to represent other methods, such as POST, PUT
>> and DELETE, in a special way, so that the user is made aware of the
>> fact that a possibly unsafe action is being requested."
>>
>> Thus, allowing a web page to submit a PUT, POST or DELETE request
>> without user interaction seems to be a very dangerous thing to me, and
>> the spec should point that out (see also
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>).
>
> I'm not sure this is much of an issue given the same-origin nature of
> the object. However, I might be mistaken...

It certainly is a problem. Again, see
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Bjoern Hoehrmann
In reply to this post by Anne van Kesteren-2

* Anne van Kesteren wrote:
>I added these, but I'm not convinced this list is a good idea anymore...  
>Firefox seems to always replace, Internet Explorer always merges headers.  
>Only Opera seems to have the logic as described by the specification. Not  
>sure about Safari. Tests are here:
>
>   http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/

Well, can we drop it and settle on append or replace then?
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Alexey Proskuryakov
In reply to this post by Julian Reschke

On 3/20/07 12:29 AM, "Julian Reschke" <[hidden email]> wrote:

>> Feedback indicated that they should all be in the list, yes.
>
> So do we have evidence of enough broken content using lowercased method
> names so that this special case makes sense?

  When we tried to remove this quirk from WebKit, the change broke some
well-known JavaScript libraries, see
<http://bugs.webkit.org/show_bug.cgi?id=8099>. One can extrapolate how
common this is likely to be the case in home-grown code.

- WBR, Alexey Proskuryakov



Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Anne van Kesteren-2
In reply to this post by Julian Reschke

On Mon, 19 Mar 2007 22:29:36 +0100, Julian Reschke <[hidden email]>  
wrote:
> I do agree that this is a good rule, but as far as I can tell, you  
> really need to state this (this==compliant implementations must  
> implement all MUST-level requirements).

Why?


>>> 2.1. Members of the XMLHttpRequest Object
>>>
>>> "When method case-insensitively matches GET, POST, HEAD, PUT or DELETE  
>>> user agents MUST use the uppercase equivalent instead."
>>>
>>> I know this is for compatibility with some broken implementations.
>>  This is for compatibility with the web.
>>
>>> [...] If this is to stay, the set of affected method names should be  
>>> revisited. Do they all need to be on this list?
>>  Feedback indicated that they should all be in the list, yes.
>
> So do we have evidence of enough broken content using lowercased method  
> names so that this special case makes sense?

Implementors said they couldn't implement anything else.


>>> "The syntax for the user or password arguments depends on the scheme  
>>> being used. If the syntax for either is incorrect per the production  
>>> given in the relevant scheme user agents must throw a SYNTAX_ERR  
>>> exception. The user and password must be encoded using the encoding  
>>> specified by the scheme. If the scheme fails to specify an encoding  
>>> they must be encoded using UTF-8."
>>>
>>> I think this has been mentioned before: does this reflect what today's  
>>> implementations do for basic and digest?
>>  I don't think so.
>
> Hm. I'm wondering whether we need to label those things of which we know  
> that they *aren't* implemented that way accordingly.

It seems unwise to annotate (almost) every sentence...


> Interesting.
>
> If the major implementations do not do this consistently, this is IMHO a  
> clear indicator that we should define new methods with clear semantics  
> (removeHeader, getHeader, addHeader...).

It's a clear indicator that setRequestHeader() needs to be fixed. I  
changed its definition now to match what Internet Explorer does. Just  
ignoring a feature that has been implemented in different ways and going  
with something now doesn't solve any problem.


> Again, the current situation is problematic because clients can not  
> reliably predict what will happen when they call setRequestHeader.  
> Either get all vendors to implement the same thing, or add new methods  
> and leave setRequestHeader underspecified.

I'm aiming for the former.


>>> "If the response is an HTTP redirect (status code 301, 302, 303 or  
>>> 307), then it MUST be transparently followed (unless it violates  
>>> security, infinite loop precautions or the scheme isn't supported).  
>>> Note that HTTP ([RFC2616]) places requirements on user agents  
>>> regarding the preservation of the request method during redirects, and  
>>> also requires users to be notified of certain kinds of automatic  
>>> redirections."
>>>
>>> To follow a redirect on a non-safe method without the user's consent  
>>> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not  
>>> sufficient.  And yes, this also applies to POST.
>>  What text would you like us to use instead?
>
> s/MUST/SHOULD/

There's already an indication of why this can fail. I think that's  
sufficient.


> Also state that this only applies to safe methods.

I think that's already clear enough as well.


>>> [...]
>
> It certainly is a problem. Again, see  
> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.

I think that's more a problem with the site in question than with XHR. For  
instance, with something as simple as a GET request you could steal  
private data.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Anne van Kesteren-2
In reply to this post by Bjoern Hoehrmann

On Tue, 20 Mar 2007 00:25:32 +0100, Bjoern Hoehrmann <[hidden email]>  
wrote:

>> I added these, but I'm not convinced this list is a good idea anymore...
>> Firefox seems to always replace, Internet Explorer always merges  
>> headers.
>> Only Opera seems to have the logic as described by the specification.  
>> Not
>> sure about Safari. Tests are here:
>>
>>   http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/
>
> Well, can we drop it and settle on append or replace then?

I settled on append which is what Internet Explorer does.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Julian Reschke
In reply to this post by Anne van Kesteren-2

Anne van Kesteren schrieb:
> On Mon, 19 Mar 2007 22:29:36 +0100, Julian Reschke
> <[hidden email]> wrote:
>> I do agree that this is a good rule, but as far as I can tell, you
>> really need to state this (this==compliant implementations must
>> implement all MUST-level requirements).
>
> Why?

It seems to me that many specs phrase it that way, but maybe that's
cosmetic.

>> Interesting.
>>
>> If the major implementations do not do this consistently, this is IMHO
>> a clear indicator that we should define new methods with clear
>> semantics (removeHeader, getHeader, addHeader...).
>
> It's a clear indicator that setRequestHeader() needs to be fixed. I
> changed its definition now to match what Internet Explorer does. Just
> ignoring a feature that has been implemented in different ways and going
> with something now doesn't solve any problem.

It now says:

"If the header argument is in the list of request headers the user agent
must either use multiple headers, combine the values or use a
combination of those (section 4.2, RFC 2616) and abort these steps.
[RFC2616]"

What's the "and abort these steps" about?

>> Again, the current situation is problematic because clients can not
>> reliably predict what will happen when they call setRequestHeader.
>> Either get all vendors to implement the same thing, or add new methods
>> and leave setRequestHeader underspecified.
>
> I'm aiming for the former.

I'd prefer the latter, unless we can get UAs fixed. Can we?

>>>> "If the response is an HTTP redirect (status code 301, 302, 303 or
>>>> 307), then it MUST be transparently followed (unless it violates
>>>> security, infinite loop precautions or the scheme isn't supported).
>>>> Note that HTTP ([RFC2616]) places requirements on user agents
>>>> regarding the preservation of the request method during redirects,
>>>> and also requires users to be notified of certain kinds of automatic
>>>> redirections."
>>>>
>>>> To follow a redirect on a non-safe method without the user's consent
>>>> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not
>>>> sufficient.  And yes, this also applies to POST.
>>>  What text would you like us to use instead?
>>
>> s/MUST/SHOULD/
>
> There's already an indication of why this can fail. I think that's
> sufficient.
>
>
>> Also state that this only applies to safe methods.
>
> I think that's already clear enough as well.

I don't think it's clear at all, unless you already know it. Currently
the description doesn't even use the term "safe", so how can it be clear?


>>>> [...]
>>
>> It certainly is a problem. Again, see
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.
>
> I think that's more a problem with the site in question than with XHR.
> For instance, with something as simple as a GET request you could steal
> private data.

No, the problem is the UA which issues an unsafe request without user
interaction.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest] last call comments

Anne van Kesteren-2

On Tue, 20 Mar 2007 16:05:26 +0100, Julian Reschke <[hidden email]>  
wrote:
> It now says:
>
> "If the header argument is in the list of request headers the user agent  
> must either use multiple headers, combine the values or use a  
> combination of those (section 4.2, RFC 2616) and abort these steps.  
> [RFC2616]"
>
> What's the "and abort these steps" about?

Well, the user agent has to follow a set of steps and at some point it has  
to abort them... Although I suppose you could argue that since it's the  
last step that phrase isn't really needed there... Removed in my local  
copy.


>>> Again, the current situation is problematic because clients can not  
>>> reliably predict what will happen when they call setRequestHeader.  
>>> Either get all vendors to implement the same thing, or add new methods  
>>> and leave setRequestHeader underspecified.
>>  I'm aiming for the former.
>
> I'd prefer the latter, unless we can get UAs fixed. Can we?

If we can't this standardization effort has been pretty pointless. Fun,  
but pointless.


>>>>> "If the response is an HTTP redirect (status code 301, 302, 303 or  
>>>>> 307), then it MUST be transparently followed (unless it violates  
>>>>> security, infinite loop precautions or the scheme isn't supported).  
>>>>> Note that HTTP ([RFC2616]) places requirements on user agents  
>>>>> regarding the preservation of the request method during redirects,  
>>>>> and also requires users to be notified of certain kinds of automatic  
>>>>> redirections."
>>>>>
>>>>> To follow a redirect on a non-safe method without the user's consent  
>>>>> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not  
>>>>> sufficient.  And yes, this also applies to POST.
>>>>  What text would you like us to use instead?
>>>
>>> s/MUST/SHOULD/
>>  There's already an indication of why this can fail. I think that's  
>> sufficient.
>>
>>> Also state that this only applies to safe methods.
>>  I think that's already clear enough as well.
>
> I don't think it's clear at all, unless you already know it. Currently  
> the description doesn't even use the term "safe", so how can it be clear?

It says "unless it violates security... precautions".


>>>>> [...]
>>>
>>> It certainly is a problem. Again, see  
>>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.
>>  I think that's more a problem with the site in question than with XHR.  
>> For instance, with something as simple as a GET request you could steal  
>> private data.
>
> No, the problem is the UA which issues an unsafe request without user  
> interaction.

Even with UA interaction you would have exactly the same problem except  
the user would also be annoyed at the UA for showing the stupid YES/NO  
dialog he knows next to nothing about except for to hit YES... The whole  
"user interaction model" is pretty broken imo.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>