XHR LC comments

[Julian Reschke]

Review of <http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/>.

General points:

a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being written
down, but if it relies on HTML5, I'd propose to consider other
publication options.

b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This may be
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.

c) Structure: It would be nice if Section 4 had more structure. Right
now it's ugly to navigate and refer to.



2.1 Dependencies

"DOM

     A conforming user agent must support some subset of the
functionality defined in DOM Events and DOM Core that this specification
relies upon. [DOM2Events] [DOM3Core]"

That reads a bit strange. Must the subset be non-empty?


2.2 Terminology

"Two URIs are same-origin if after performing scheme-based normalization
on both URIs as described in section 5.3.3 of RFC 3987 the scheme, ihost
and port components are identical. If either URI does not have an ihost
component the URIs must not  be considered same-origin. [RFC3987]"

Why are we referring to the IRI spec (RFC3987) when talking about URIs,
as defined RFC3986?


3. Security Considerations

"Apart from requirements affecting security made throughout this
specification implementations may, at their discretion, not expose
certain headers, such as HttpOnly cookies."

"...such as headers containing HttpOnly cookies".

Besides that: this may be a non-optimal example unless we can point to a
definition of "HttpOnly cookies". Can we?


4. The XMLHttpRequest Object

"onreadystatechange of type EventListener

     This attribute is an event handler DOM attribute and must be
invoked whenever a readystatechange event is targated at the object."

s/targated/targeted/

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

- missing comma after OPTIONS
- TRACK??? There's probably a rational for that. If there is, please
include it in the spec.


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

Why is XHR talking about the encoding here? Is "stored user" a string or
a byte array?

(same for password)


"Abort the send() algorithm, set response entity body to "null" and
reset the list of request headers."

This is a very confusing statement, until one realizes that it's in the
description of "open", not "send". It would be good to rephrase this so
it becomes clear that this aborts a *previous* send request.



"If the value argument is null terminate these steps. (Do not raise an
exception.)."

This makes it impossible to set empty headers, which are allowed in
HTTP. Even worse, it silently fails.

This is profiling of the base spec, and I don't see any compelling
reason to do so. Don't do it.


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

It's unclear why there's a security reason not to allow things like
"Accept-Charset" or "Accept-Encoding". Please explain.


General comment on "setRequestHeader(header, value), method": the way it
is specified makes it impossible for a client to reliably set headers.
We need a way to either retrieve the current value for inspection, or a
way to reset the header. Or both.


"If stored method is GET act as if the data argument is null."

Another case of HTTP/1.1 being profiled. Don't do it.


"Serialize data into a namespace well-formed XML document and encoded
using the encoding given by data.inputEncoding, when not null, or UTF-8
otherwise. Or, if this fails because the Document cannot be serialized
act as if data  is null."

Silent failure????


"If no Content-Type header has been set using setRequestHeader() append
a Content-Type header to the list of request headers with a value of
application/xml;charset=charset  where charset is the encoding used to
encode the document."

This will result in an invalid Content-Type header if the UA has
initialized the headers with a default (which I think the spec currently
allows; and at least one UA was reported to do). See comment above about
header handling.


"While downloading the resource the following rules are to be observed."

That reads strange. HTTP requests do not "download" resources. Say
"while executing the request".


"If the user agent supports HTTP State Management 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]"

This should probably include a reference to the Set-Cookie (not
Set-Cookie2) spec as well (RFC2109).


"If the user agent implements server-driven content-negotiation it
should set Accept-Encoding and Accept-Charset headers as appropriate; it
must not automatically set the Accept."

s/set the Accept/set the Accept header/


"Responses to such requests must have the content-encodings
automatically decoded. [RFC2616]"

"Such requests" is a bit fuzzy here. Please rephrase in terms of what
the response contains (such as Content-Encoding header being present etc).


"// The following script:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
  if(this.readyState == 3) {
   print(this.getAllResponseHeaders());
  }
}

// ...should output something similar to the following text:
Date: Sun, 24 Oct 2004 04:58:38 GMT
Server: Apache/1.3.31 (Unix)
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8"

I think examples like this would be more readable (and take less space)
when using the syncr. mode.


"status of type unsigned short, readonly

On getting, if available, it must return the HTTP status code sent by
the server (typically 200 for a successful request). Otherwise, if not
available, the user agent must raise an INVALID_STATE_ERR exception."

This may be incorrect when the UA caches (304 vs 200).


"statusText of type DOMString, readonly

     On getting, if available, it must return the HTTP status text sent
by the server (appears after the status code). Otherwise, if not
available, the user agent must raise an INVALID_STATE_ERR exception."

Really? It seems to me that if somebody really implements this, clients
are likely to break. Why not allow an empty string here?


Finally, 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>).

[Sunava Dutta]

Julian Reschke wrote:
a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being written
down, but if it relies on HTML5, I'd propose to consider other
publication options.

>>+1. I had suggested something along the lines of not linking to other specifications that are moving targets but other publication options if we do decide to go this route are fine.

"Ensure all new entities like constants, flags etc are versioned or in a new object.
The draft frequently cross references specifications in the W3C.For example, the spec makes references to the DOM 3 events and core, namespaces in XML, Window Object 1.0 etc (Some of which are drafts themselves). We fail to see the value in implicitly embedding other large specs. Simplicity and standing on its own would be good."

Julian Reschke wrote:

b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This may be
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.

>>+1

Julian Reschke wrote:
c)
"- TRACK??? There's probably a rational for that. If there is, please
include it in the spec."

>>TRACK is unsafe and should be removed. I remember reading about this awhile back. Here's something I found on the web: http://www.aqtronix.com/Advisories/AQ-2003-02.txt

Julian Reschke wrote:
d)
""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."

Why is XHR talking about the encoding here? Is "stored user" a string or
a byte array?

(same for password)"


>>+1. I'm not quite sure what this means and the relevancy.

Julian Reschke wrote:
e)
"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 "

It's unclear why there's a security reason not to allow things like
"Accept-Charset" or "Accept-Encoding". Please explain."

>>+1. I've given this feedback before but haven't heard back anything. We should mention why these are bad and also consider what is currently allowed today by UA's.
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0191.html




-----Original Message-----
From: public-webapi-request@... [mailto:public-webapi-request@...] On Behalf Of Julian Reschke
Sent: Sunday, May 04, 2008 2:47 AM
To: public-webapi@...
Subject: XHR LC comments


Review of <http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/>.

General points:

a) I'm confused about the approach to this document. On the one hand,
we're being told that it can't define anything not already in use (and
that new stuff belongs into XHR2), on the other hand it relies on HTML5,
which is a moving target. It's good that this stuff is being written
down, but if it relies on HTML5, I'd propose to consider other
publication options.

b) Algorithms: the spec uses a method to describe algorithms that IMHO
is extremely hard to read (see for instance send() method). This may be
good for implementors, but seems to be bad for everybody else.
Minimally, the lists should be structured for better readability.

c) Structure: It would be nice if Section 4 had more structure. Right
now it's ugly to navigate and refer to.



2.1 Dependencies

"DOM

     A conforming user agent must support some subset of the
functionality defined in DOM Events and DOM Core that this specification
relies upon. [DOM2Events] [DOM3Core]"

That reads a bit strange. Must the subset be non-empty?


2.2 Terminology

"Two URIs are same-origin if after performing scheme-based normalization
on both URIs as described in section 5.3.3 of RFC 3987 the scheme, ihost
and port components are identical. If either URI does not have an ihost
component the URIs must not  be considered same-origin. [RFC3987]"

Why are we referring to the IRI spec (RFC3987) when talking about URIs,
as defined RFC3986?


3. Security Considerations

"Apart from requirements affecting security made throughout this
specification implementations may, at their discretion, not expose
certain headers, such as HttpOnly cookies."

"...such as headers containing HttpOnly cookies".

Besides that: this may be a non-optimal example unless we can point to a
definition of "HttpOnly cookies". Can we?


4. The XMLHttpRequest Object

"onreadystatechange of type EventListener

     This attribute is an event handler DOM attribute and must be
invoked whenever a readystatechange event is targated at the object."

s/targated/targeted/

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

- missing comma after OPTIONS
- TRACK??? There's probably a rational for that. If there is, please
include it in the spec.


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

Why is XHR talking about the encoding here? Is "stored user" a string or
a byte array?

(same for password)


"Abort the send() algorithm, set response entity body to "null" and
reset the list of request headers."

This is a very confusing statement, until one realizes that it's in the
description of "open", not "send". It would be good to rephrase this so
it becomes clear that this aborts a *previous* send request.



"If the value argument is null terminate these steps. (Do not raise an
exception.)."

This makes it impossible to set empty headers, which are allowed in
HTTP. Even worse, it silently fails.

This is profiling of the base spec, and I don't see any compelling
reason to do so. Don't do it.


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

It's unclear why there's a security reason not to allow things like
"Accept-Charset" or "Accept-Encoding". Please explain.


General comment on "setRequestHeader(header, value), method": the way it
is specified makes it impossible for a client to reliably set headers.
We need a way to either retrieve the current value for inspection, or a
way to reset the header. Or both.


"If stored method is GET act as if the data argument is null."

Another case of HTTP/1.1 being profiled. Don't do it.


"Serialize data into a namespace well-formed XML document and encoded
using the encoding given by data.inputEncoding, when not null, or UTF-8
otherwise. Or, if this fails because the Document cannot be serialized
act as if data  is null."

Silent failure????


"If no Content-Type header has been set using setRequestHeader() append
a Content-Type header to the list of request headers with a value of
application/xml;charset=charset  where charset is the encoding used to
encode the document."

This will result in an invalid Content-Type header if the UA has
initialized the headers with a default (which I think the spec currently
allows; and at least one UA was reported to do). See comment above about
header handling.


"While downloading the resource the following rules are to be observed."

That reads strange. HTTP requests do not "download" resources. Say
"while executing the request".


"If the user agent supports HTTP State Management 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]"

This should probably include a reference to the Set-Cookie (not
Set-Cookie2) spec as well (RFC2109).


"If the user agent implements server-driven content-negotiation it
should set Accept-Encoding and Accept-Charset headers as appropriate; it
must not automatically set the Accept."

s/set the Accept/set the Accept header/


"Responses to such requests must have the content-encodings
automatically decoded. [RFC2616]"

"Such requests" is a bit fuzzy here. Please rephrase in terms of what
the response contains (such as Content-Encoding header being present etc).


"// The following script:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
  if(this.readyState == 3) {
   print(this.getAllResponseHeaders());
  }
}

// ...should output something similar to the following text:
Date: Sun, 24 Oct 2004 04:58:38 GMT
Server: Apache/1.3.31 (Unix)
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8"

I think examples like this would be more readable (and take less space)
when using the syncr. mode.


"status of type unsigned short, readonly

On getting, if available, it must return the HTTP status code sent by
the server (typically 200 for a successful request). Otherwise, if not
available, the user agent must raise an INVALID_STATE_ERR exception."

This may be incorrect when the UA caches (304 vs 200).


"statusText of type DOMString, readonly

     On getting, if available, it must return the HTTP status text sent
by the server (appears after the status code). Otherwise, if not
available, the user agent must raise an INVALID_STATE_ERR exception."

Really? It seems to me that if somebody really implements this, clients
are likely to break. Why not allow an empty string here?


Finally, 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>).

[Julian Reschke]

Sunava,

it would be helpful if you'd use a mail client that can properly quote
:-) In your mail your text appears as if it was indirectly quoted by
myself... I have reformatted your reply so it becomes clear again who
said what.

Sunava Dutta wrote:
>> Julian Reschke wrote:
>> c)
>> "- TRACK??? There's probably a rational for that. If there is, please
>> include it in the spec."
>
>TRACK is unsafe and should be removed. I remember reading about this awhile back. Here's something I found on the web: http://www.aqtronix.com/Advisories/AQ-2003-02.txt

That implies that Microsoft closed the vulnerability with IIS 6.0, so
I'm not entirely sure why a spec in last call in 2008 needs to speak
about it.

There are surely other old servers that have other vulnerabilities that
could be exploited using XHR, should we consider all of these?

That being said, I'm ok with *mentioning* the issue somewhere, but just
enumerating TRACK along with TRACE, as if this was a standard HTTP
method, is *highly* confusing.

 > ...

BR, Julian

[Sunava Dutta]

Ahh, I see my mail client can do that. I just need to make a few changes. Having a standardized guidance here would be very helpful -:p.


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...]
Sent: Tuesday, May 06, 2008 12:34 AM
To: Sunava Dutta
Cc: public-webapi@...; IE8 Core AJAX SWAT Team
Subject: Re: XHR LC comments

Sunava,

it would be helpful if you'd use a mail client that can properly quote
:-) In your mail your text appears as if it was indirectly quoted by
myself... I have reformatted your reply so it becomes clear again who
said what.

Sunava Dutta wrote:
>> Julian Reschke wrote:
>> c)
>> "- TRACK??? There's probably a rational for that. If there is, please
>> include it in the spec."
>
>TRACK is unsafe and should be removed. I remember reading about this awhile back. Here's something I found on the web: http://www.aqtronix.com/Advisories/AQ-2003-02.txt

That implies that Microsoft closed the vulnerability with IIS 6.0, so
I'm not entirely sure why a spec in last call in 2008 needs to speak
about it.

There are surely other old servers that have other vulnerabilities that
could be exploited using XHR, should we consider all of these?

That being said, I'm ok with *mentioning* the issue somewhere, but just
enumerating TRACK along with TRACE, as if this was a standard HTTP
method, is *highly* confusing.

 > ...

BR, Julian

[Anne van Kesteren-2]

On Sun, 04 May 2008 11:47:13 +0200, Julian Reschke <julian.reschke@...>  
wrote:

> Review of <http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/>.
>
> General points:
>
> a) I'm confused about the approach to this document. On the one hand,  
> we're being told that it can't define anything not already in use (and  
> that new stuff belongs into XHR2), on the other hand it relies on HTML5,  
> which is a moving target. It's good that this stuff is being written  
> down, but if it relies on HTML5, I'd propose to consider other  
> publication options.

The problem is that concepts such "origin" and determining the encoding of  
a text/html stream are not defined anywhere else. It's not really clear to  
me what to do about that.


> b) Algorithms: the spec uses a method to describe algorithms that IMHO  
> is extremely hard to read (see for instance send() method). This may be  
> good for implementors, but seems to be bad for everybody else.  
> Minimally, the lists should be structured for better readability.

Could you elaborate on what kind of change you envision? I'm not sure how  
they are not structured right now.


> c) Structure: It would be nice if Section 4 had more structure. Right  
> now it's ugly to navigate and refer to.

This is better in XMLHttpRequest Level 2. I rather not revise that entire  
section editorially as it might introduce new errors.


> 2.1 Dependencies
>
> "DOM
>
>      A conforming user agent must support some subset of the  
> functionality defined in DOM Events and DOM Core that this specification  
> relies upon. [DOM2Events] [DOM3Core]"
>
> That reads a bit strange. Must the subset be non-empty?

Yes, as stated it must be a subset that matches what XMLHttpRequest  
requires from the eventing and core specifications.


> 2.2 Terminology
>
> "Two URIs are same-origin if after performing scheme-based normalization  
> on both URIs as described in section 5.3.3 of RFC 3987 the scheme, ihost  
> and port components are identical. If either URI does not have an ihost  
> component the URIs must not  be considered same-origin. [RFC3987]"
>
> Why are we referring to the IRI spec (RFC3987) when talking about URIs,  
> as defined RFC3986?

For scheme-bases normalization and ihost. Maybe I should use IRI instead  
of URI?


> 3. Security Considerations
>
> "Apart from requirements affecting security made throughout this  
> specification implementations may, at their discretion, not expose  
> certain headers, such as HttpOnly cookies."
>
> "...such as headers containing HttpOnly cookies".

Done.


> Besides that: this may be a non-optimal example unless we can point to a  
> definition of "HttpOnly cookies". Can we?

I don't believe we can, but since this was put in mostly for HttpOnly  
cookies I rather not remove that. I think it will be clear enough for  
people reading the document.


> 4. The XMLHttpRequest Object
>
> "onreadystatechange of type EventListener
>
>      This attribute is an event handler DOM attribute and must be  
> invoked whenever a readystatechange event is targated at the object."
>
> s/targated/targeted/

Already fixed.


> "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."
>
> - missing comma after OPTIONS

Fixed.


> - TRACK??? There's probably a rational for that. If there is, please  
> include it in the spec.

It's a security issue, as should be clear from the next bullet point.


> "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."
>
> Why is XHR talking about the encoding here? Is "stored user" a string or  
> a byte array?
>
> (same for password)

They're a string (in the API).


> "Abort the send() algorithm, set response entity body to "null" and  
> reset the list of request headers."
>
> This is a very confusing statement, until one realizes that it's in the  
> description of "open", not "send". It would be good to rephrase this so  
> it becomes clear that this aborts a *previous* send request.

Added a note.


> "If the value argument is null terminate these steps. (Do not raise an  
> exception.)."
>
> This makes it impossible to set empty headers, which are allowed in  
> HTTP. Even worse, it silently fails.

Empty headers can be set using the empty string, no? Not raising an  
exception is consistent with implementations and I don't think it matters  
much as it doesn't have any effect.


> This is profiling of the base spec, and I don't see any compelling  
> reason to do so. Don't do it.

How is it profiling?

> "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 "
>
> It's unclear why there's a security reason not to allow things like  
> "Accept-Charset" or "Accept-Encoding". Please explain.

This was done based on implementation feedback. I haven't investigated  
what the reasons were for the various headers. If implementors read this  
maybe they could chime in and point it out.


> General comment on "setRequestHeader(header, value), method": the way it  
> is specified makes it impossible for a client to reliably set headers.  
> We need a way to either retrieve the current value for inspection, or a  
> way to reset the header. Or both.

http://lists.w3.org/Archives/Public/public-webapi/2008May/0139.html


> "If stored method is GET act as if the data argument is null."
>
> Another case of HTTP/1.1 being profiled. Don't do it.

This was done on request of implementations.


> "Serialize data into a namespace well-formed XML document and encoded  
> using the encoding given by data.inputEncoding, when not null, or UTF-8  
> otherwise. Or, if this fails because the Document cannot be serialized  
> act as if data  is null."
>
> Silent failure????

Yes.


> "If no Content-Type header has been set using setRequestHeader() append  
> a Content-Type header to the list of request headers with a value of  
> application/xml;charset=charset  where charset is the encoding used to  
> encode the document."
>
> This will result in an invalid Content-Type header if the UA has  
> initialized the headers with a default (which I think the spec currently  
> allows; and at least one UA was reported to do). See comment above about  
> header handling.

Rephrased.


> "While downloading the resource the following rules are to be observed."
>
> That reads strange. HTTP requests do not "download" resources. Say  
> "while executing the request".

Thanks, fixed.


> "If the user agent supports HTTP State Management 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]"
>
> This should probably include a reference to the Set-Cookie (not  
> Set-Cookie2) spec as well (RFC2109).

I believe it used to do that and it was pointed out that that  
specification is not useful in practice and would actually do more harm  
than good. I'm not really sure what to do here.


> "If the user agent implements server-driven content-negotiation it  
> should set Accept-Encoding and Accept-Charset headers as appropriate; it  
> must not automatically set the Accept."
>
> s/set the Accept/set the Accept header/

Fixed due to other changes.


> "Responses to such requests must have the content-encodings  
> automatically decoded. [RFC2616]"
>
> "Such requests" is a bit fuzzy here. Please rephrase in terms of what  
> the response contains (such as Content-Encoding header being present  
> etc).

I simply dropped "to such requests". I hope that's ok.

> "// The following script:
> var client = new XMLHttpRequest();
> client.open("GET", "test.txt", true);
> client.send();
> client.onreadystatechange = function() {
>   if(this.readyState == 3) {
>    print(this.getAllResponseHeaders());
>   }
> }
>
> // ...should output something similar to the following text:
> Date: Sun, 24 Oct 2004 04:58:38 GMT
> Server: Apache/1.3.31 (Unix)
> Keep-Alive: timeout=15, max=99
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/plain; charset=utf-8"
>
> I think examples like this would be more readable (and take less space)  
> when using the syncr. mode.

I would like to avoid encouraging authors to use the synchronous API.


> "status of type unsigned short, readonly
>
> On getting, if available, it must return the HTTP status code sent by  
> the server (typically 200 for a successful request). Otherwise, if not  
> available, the user agent must raise an INVALID_STATE_ERR exception."
>
> This may be incorrect when the UA caches (304 vs 200).

That's why it says typically.


> "statusText of type DOMString, readonly
>
>      On getting, if available, it must return the HTTP status text sent  
> by the server (appears after the status code). Otherwise, if not  
> available, the user agent must raise an INVALID_STATE_ERR exception."
>
> Really? It seems to me that if somebody really implements this, clients  
> are likely to break. Why not allow an empty string here?

This is what clients have implemented as far as I can tell. Though the  
HTTP status text could be the empty string, if that's what you mean...

> Finally, 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>).

All requirements from HTTP are taken over unless explicitly stated so I  
don't think this is needed.

Kind regards,


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

[Julian Reschke]

Anne van Kesteren wrote:

> On Sun, 04 May 2008 11:47:13 +0200, Julian Reschke
> <julian.reschke@...> wrote:
>> Review of <http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/>.
>>
>> General points:
>>
>> a) I'm confused about the approach to this document. On the one hand,
>> we're being told that it can't define anything not already in use (and
>> that new stuff belongs into XHR2), on the other hand it relies on
>> HTML5, which is a moving target. It's good that this stuff is being
>> written down, but if it relies on HTML5, I'd propose to consider other
>> publication options.
>
> The problem is that concepts such "origin" and determining the encoding
> of a text/html stream are not defined anywhere else. It's not really
> clear to me what to do about that.

In some cases, it may be possible to copy the current definition. In
other cases, it may be possible just not to depend on it (for instance,
by not specifying encoding sniffing).

>> b) Algorithms: the spec uses a method to describe algorithms that IMHO
>> is extremely hard to read (see for instance send() method). This may
>> be good for implementors, but seems to be bad for everybody else.
>> Minimally, the lists should be structured for better readability.
>
> Could you elaborate on what kind of change you envision? I'm not sure
> how they are not structured right now.

An example would be steps 8..11 in the description of open():

- these steps deal with credentials, and the whole list would be more
readable if each group of steps that belong together would me structured
that way;

- optimally, thing like this shouldn't be expressed as a set of
instructions, but in a declarative way.

>> c) Structure: It would be nice if Section 4 had more structure. Right
>> now it's ugly to navigate and refer to.
>
> This is better in XMLHttpRequest Level 2. I rather not revise that
> entire section editorially as it might introduce new errors.

But then, it makes a comparison with XHR2 harder. Please reconsider.

>> 2.1 Dependencies
>>
>> "DOM
>>
>>      A conforming user agent must support some subset of the
>> functionality defined in DOM Events and DOM Core that this
>> specification relies upon. [DOM2Events] [DOM3Core]"
>>
>> That reads a bit strange. Must the subset be non-empty?
>
> Yes, as stated it must be a subset that matches what XMLHttpRequest
> requires from the eventing and core specifications.

Then it would be clearer if it said "the subset" instead of "some subset".

>> 2.2 Terminology
>>
>> "Two URIs are same-origin if after performing scheme-based
>> normalization on both URIs as described in section 5.3.3 of RFC 3987
>> the scheme, ihost and port components are identical. If either URI
>> does not have an ihost component the URIs must not  be considered
>> same-origin. [RFC3987]"
>>
>> Why are we referring to the IRI spec (RFC3987) when talking about
>> URIs, as defined RFC3986?
>
> For scheme-bases normalization and ihost. Maybe I should use IRI instead
> of URI?

Well, if we're talking about URIs (and I think we do), then we need to
refer to RFC3986 grammar and comparison rules.

>> Besides that: this may be a non-optimal example unless we can point to
>> a definition of "HttpOnly cookies". Can we?
>
> I don't believe we can, but since this was put in mostly for HttpOnly
> cookies I rather not remove that. I think it will be clear enough for
> people reading the document.

So why don't we refer to the specification for httpOnly? Do you consider
it a problem that it's a Microsoft document?

>> - TRACK??? There's probably a rational for that. If there is, please
>> include it in the spec.
>
> It's a security issue, as should be clear from the next bullet point.

As TRACK doesn't seem to be documented anywhere, and not implemented in
current IIS versions anymore, I'd really like to see this made a foot
node. The way it's written now is just totally confusing to every reader
who doesn't know the full story around it.

>> "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."
>>
>> Why is XHR talking about the encoding here? Is "stored user" a string
>> or a byte array?
>>
>> (same for password)
>
> They're a string (in the API).

When they are a string, then taking about character encoding doesn't
make any sense here.

>> "If the value argument is null terminate these steps. (Do not raise an
>> exception.)."
>>
>> This makes it impossible to set empty headers, which are allowed in
>> HTTP. Even worse, it silently fails.
>
> Empty headers can be set using the empty string, no? Not raising an
> exception is consistent with implementations and I don't think it
> matters much as it doesn't have any effect.

Sorry, was reading one thing, but thinking about something else.

Thinking of it, could you please add a clarification that setting to an
empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX) implementation got that wrong, not
setting the header at all.

>> "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 "
>>
>> It's unclear why there's a security reason not to allow things like
>> "Accept-Charset" or "Accept-Encoding". Please explain.
>
> This was done based on implementation feedback. I haven't investigated
> what the reasons were for the various headers. If implementors read this
> maybe they could chime in and point it out.

Please. And if they don't, please remove all headers for which nobody
can explain why they are in this list.

>> General comment on "setRequestHeader(header, value), method": the way
>> it is specified makes it impossible for a client to reliably set
>> headers. We need a way to either retrieve the current value for
>> inspection, or a way to reset the header. Or both.
>
> http://lists.w3.org/Archives/Public/public-webapi/2008May/0139.html

Yes, we continue to disagree on this.

>> "If stored method is GET act as if the data argument is null."
>>
>> Another case of HTTP/1.1 being profiled. Don't do it.
>
> This was done on request of implementations.

That's IMHO not sufficient reason to do it. Please add a convincing
rational, or leave this to the HTTP WG.

>> "Serialize data into a namespace well-formed XML document and encoded
>> using the encoding given by data.inputEncoding, when not null, or
>> UTF-8 otherwise. Or, if this fails because the Document cannot be
>> serialized act as if data  is null."
>>
>> Silent failure????
>
> Yes.

Very bad.

Does anybody rely on that? I would be very suprised.

>> "If no Content-Type header has been set using setRequestHeader()
>> append a Content-Type header to the list of request headers with a
>> value of application/xml;charset=charset  where charset is the
>> encoding used to encode the document."
>>
>> This will result in an invalid Content-Type header if the UA has
>> initialized the headers with a default (which I think the spec
>> currently allows; and at least one UA was reported to do). See comment
>> above about header handling.
>
> Rephrased.

Pointer?

>> "If the user agent supports HTTP State Management 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]"
>>
>> This should probably include a reference to the Set-Cookie (not
>> Set-Cookie2) spec as well (RFC2109).
>
> I believe it used to do that and it was pointed out that that
> specification is not useful in practice and would actually do more harm
> than good. I'm not really sure what to do here.

Well, the one that is not used in practice is RFC2965, not RFC2109. That
being said, you probably need to reference both.

>> "// The following script:
>> var client = new XMLHttpRequest();
>> client.open("GET", "test.txt", true);
>> client.send();
>> client.onreadystatechange = function() {
>>   if(this.readyState == 3) {
>>    print(this.getAllResponseHeaders());
>>   }
>> }
>>
>> // ...should output something similar to the following text:
>> Date: Sun, 24 Oct 2004 04:58:38 GMT
>> Server: Apache/1.3.31 (Unix)
>> Keep-Alive: timeout=15, max=99
>> Connection: Keep-Alive
>> Transfer-Encoding: chunked
>> Content-Type: text/plain; charset=utf-8"
>>
>> I think examples like this would be more readable (and take less
>> space) when using the syncr. mode.
>
> I would like to avoid encouraging authors to use the synchronous API.

Disagreed. I think readability and compactness is more important here.

>> "status of type unsigned short, readonly
>>
>> On getting, if available, it must return the HTTP status code sent by
>> the server (typically 200 for a successful request). Otherwise, if not
>> available, the user agent must raise an INVALID_STATE_ERR exception."
>>
>> This may be incorrect when the UA caches (304 vs 200).
>
> That's why it says typically.

Hm, no.

When the UA caches, and the server sent 304, the client will potentially
see a 200. This would contradict what *this* paragraph says.

>> "statusText of type DOMString, readonly
>>
>>      On getting, if available, it must return the HTTP status text
>> sent by the server (appears after the status code). Otherwise, if not
>> available, the user agent must raise an INVALID_STATE_ERR exception."
>>
>> Really? It seems to me that if somebody really implements this,
>> clients are likely to break. Why not allow an empty string here?
>
> This is what clients have implemented as far as I can tell. Though the
> HTTP status text could be the empty string, if that's what you mean...

Does the "if not available" apply to any of the existing
implementations? Why would it be "not available"? Please clarify.

>> Finally, 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>).
>
> All requirements from HTTP are taken over unless explicitly stated so I
> don't think this is needed.

Well, the spec repeats lots of things specified somewhere else already.

The warning from the HTTP spec is relevant and should appear here, as
XHR is related to UAs, and existing UAs are known to ignore this
security consideration.

BR, Julian

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:

>> "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 "
>>
>> It's unclear why there's a security reason not to allow things like  
>> "Accept-Charset" or "Accept-Encoding". Please explain.
>
>This was done based on implementation feedback. I haven't investigated  
>what the reasons were for the various headers. If implementors read this  
>maybe they could chime in and point it out.

Note that there are more headers on the list than the ones listed above,
specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the
Cookie and Authorization header.

The correct value, if any, of the Connection, Content-Length, Expect,
Keep-Alive, Trailer, Transfer-Encoding, and Upgrade depends on decisions
about how to transfer the message and how to maintain the connection
that the implementation alone can make, therefore the implementation
rather than the script controls these headers. The Host header is on the
list to ensure scripts cannot bypass same origin restrictions.

Date, Referer, and Via inform about the origin of the request, they are
controlled by the implementation to prevent origin spoofing. The case
for these is much less clear, considering that other headers like User-
Agent are not on the list, and that cross-site requests are not allowed.

Accept-Charset, Accept-Encoding, and TE inform about client capabilities
and it seems the worst that could happen for them is that the server
offers a response the implementation cannot handle, which the server may
do anyway. I don't think their presence is particularily justified. This
is also because some environments treat "X-Y" named headers as if they
were "X_Y" headers and vice versa, if, say, Accept-Encoding is a problem
so would be Accept_Encoding.

Why Content-Transfer-Encoding is on the list I have no idea, HTTP does
not use this header at all, and when I researched this some months ago,
I could not find any particular security problems associated to it, as
far as I remember.

I very much agree the rationale for each header needs to be in the spec,
in a manner that also allows telling why other headers are not.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Ian Hickson]

On Wed, 14 May 2008, Julian Reschke wrote:
> >
> > The problem is that concepts such "origin" and determining the
> > encoding of a text/html stream are not defined anywhere else. It's not
> > really clear to me what to do about that.
>
> In some cases, it may be possible to copy the current definition. In
> other cases, it may be possible just not to depend on it (for instance,
> by not specifying encoding sniffing).

I don't have an opinion on the exact issue here, but as a general rule I
recommend against making decisions based on the political status (rather
than technical status) of working groups and specs. Otherwise we just end
up reinforcing the Web's experiment with Conway's Law. That is to say, we
should rather change the rules that prevent us from doing the right thing,
than blindly follow those rules and change our technology to match.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ian Hickson]

On Wed, 14 May 2008, Bjoern Hoehrmann wrote:
>
> Note that there are more headers on the list than the ones listed above,
> specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the
> Cookie and Authorization header.

I think I would lump the Cookie, Cookie2, and Authorization headers in the
same bucket as, e.g., Host -- these are headers that the UA should be
setting and not headers that should be under author control.

Incidentally, I think I would recommend removing the blacklist from AC,
since AC has a whitelist. Having both seems pointless.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:
> ...
> Incidentally, I think I would recommend removing the blacklist from AC,
> since AC has a whitelist. Having both seems pointless.
> ...

You mean disallowing all headers except a known list??? Nope.

Again, that would mean profiling HTTP, and make it impossible to deploy
new stuff.

BR, Julian

[Julian Reschke]

Ian Hickson wrote:

> On Wed, 14 May 2008, Julian Reschke wrote:
>>> The problem is that concepts such "origin" and determining the
>>> encoding of a text/html stream are not defined anywhere else. It's not
>>> really clear to me what to do about that.
>> In some cases, it may be possible to copy the current definition. In
>> other cases, it may be possible just not to depend on it (for instance,
>> by not specifying encoding sniffing).
>
> I don't have an opinion on the exact issue here, but as a general rule I
> recommend against making decisions based on the political status (rather
> than technical status) of working groups and specs. Otherwise we just end

Not sure what this means.

My understanding was that XHR1 is an intermediate step (documenting the
current state, and trying to make it more interoperable), while XHR2
would contain something that is really good.

If this is the case, it's totally pointless to let XHR1 have normative
references on something that won't be finished for a long time.

> ...

BR, Julian

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:

> Ian Hickson wrote:
> > ...
> > Incidentally, I think I would recommend removing the blacklist from AC,
> > since AC has a whitelist. Having both seems pointless.
> > ...
>
> You mean disallowing all headers except a known list??? Nope.
>
> Again, that would mean profiling HTTP, and make it impossible to deploy new
> stuff.

It's what XHR2+AC already requires, I'm just suggesting simplifying the
prose of AC to remove the redundant blacklist (since it doesn't have any
testable block-box effect).

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:

> >
> > I don't have an opinion on the exact issue here, but as a general rule
> > I recommend against making decisions based on the political status
> > (rather than technical status) of working groups and specs. Otherwise
> > we just end [up invoking Conway's law]
>
> My understanding was that XHR1 is an intermediate step (documenting the
> current state, and trying to make it more interoperable), while XHR2
> would contain something that is really good.
>
> If this is the case, it's totally pointless to let XHR1 have normative
> references on something that won't be finished for a long time.

Pragmatically, why does it matter when the references are finished?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:
>> My understanding was that XHR1 is an intermediate step (documenting the
>> current state, and trying to make it more interoperable), while XHR2
>> would contain something that is really good.
>>
>> If this is the case, it's totally pointless to let XHR1 have normative
>> references on something that won't be finished for a long time.
>
> Pragmatically, why does it matter when the references are finished?

The spec can't be more "ready" than all normative references.

If these aren't getting ready in time, then I'm not sure why XHR1 needs
to be on the W3C REC track at all.

BR, Julian

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:
>
> The spec can't be more "ready" than all normative references.

Sure it can. The concept of "origin" (for instance) is pretty well
understood by browser vendors, and HTML5 is getting progressively closer
to defining it. XHR1 doesn't need it to be perfectly defined to make use
of it. Same with Window, probably even more so in fact.


> If these aren't getting ready in time, then I'm not sure why XHR1 needs
> to be on the W3C REC track at all.

Well, personally I don't mind what organisation publishes the spec. The
WHATWG would, I'm sure, be happy to publish the XHR spec if the W3C didn't
want to do it -- indeed, that's where XMLHttpRequest started its standards
career in the first place.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:
> On Thu, 15 May 2008, Julian Reschke wrote:
>> The spec can't be more "ready" than all normative references.
>
> Sure it can. The concept of "origin" (for instance) is pretty well
> understood by browser vendors, and HTML5 is getting progressively closer
> to defining it. XHR1 doesn't need it to be perfectly defined to make use
> of it. Same with Window, probably even more so in fact.

So why then is the reference to HTML5 needed?

> ...

BR, Julian

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:

> Ian Hickson wrote:
> > On Thu, 15 May 2008, Julian Reschke wrote:
> > > The spec can't be more "ready" than all normative references.
> >
> > Sure it can. The concept of "origin" (for instance) is pretty well
> > understood by browser vendors, and HTML5 is getting progressively closer to
> > defining it. XHR1 doesn't need it to be perfectly defined to make use of it.
> > Same with Window, probably even more so in fact.
>
> So why then is the reference to HTML5 needed?

Wouldn't you just complain that Window and 'origin' were totally undefined
if we used them without referencing something?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:

> On Thu, 15 May 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> On Thu, 15 May 2008, Julian Reschke wrote:
>>>> The spec can't be more "ready" than all normative references.
>>> Sure it can. The concept of "origin" (for instance) is pretty well
>>> understood by browser vendors, and HTML5 is getting progressively closer to
>>> defining it. XHR1 doesn't need it to be perfectly defined to make use of it.
>>> Same with Window, probably even more so in fact.
>> So why then is the reference to HTML5 needed?
>
> Wouldn't you just complain that Window and 'origin' were totally undefined
> if we used them without referencing something?

That wasn't what I was suggesting.

BR, Julian

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:

> Ian Hickson wrote:
> > On Thu, 15 May 2008, Julian Reschke wrote:
> > > Ian Hickson wrote:
> > > > On Thu, 15 May 2008, Julian Reschke wrote:
> > > > > The spec can't be more "ready" than all normative references.
> > > > Sure it can. The concept of "origin" (for instance) is pretty well
> > > > understood by browser vendors, and HTML5 is getting progressively closer
> > > > to
> > > > defining it. XHR1 doesn't need it to be perfectly defined to make use of
> > > > it.
> > > > Same with Window, probably even more so in fact.
> > > So why then is the reference to HTML5 needed?
> >
> > Wouldn't you just complain that Window and 'origin' were totally undefined
> > if we used them without referencing something?
>
> That wasn't what I was suggesting.

So what are you suggesting?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:

> On Thu, 15 May 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> On Thu, 15 May 2008, Julian Reschke wrote:
>>>> Ian Hickson wrote:
>>>>> On Thu, 15 May 2008, Julian Reschke wrote:
>>>>>> The spec can't be more "ready" than all normative references.
>>>>> Sure it can. The concept of "origin" (for instance) is pretty well
>>>>> understood by browser vendors, and HTML5 is getting progressively closer
>>>>> to
>>>>> defining it. XHR1 doesn't need it to be perfectly defined to make use of
>>>>> it.
>>>>> Same with Window, probably even more so in fact.
>>>> So why then is the reference to HTML5 needed?
>>> Wouldn't you just complain that Window and 'origin' were totally undefined
>>> if we used them without referencing something?
>> That wasn't what I was suggesting.
>
> So what are you suggesting?

I would suggest to either copy over what HTML5 currently says, or to
reference something that can be considered a stable reference.

BR, Julian