Re: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:
- If the URL parameter can be a IRI, then somewhere later on we need 
to state that it needs to be transformed to a URI before it's put on 
the wire.


Added a transformation step as per 3.1 and also required throwing a 
SYNTAX_ERR in case of failure (ToASCII operation failure seems the most 
likely).


OK, it would probably make sense then to rename the URL parameter and 
stored URL accordingly, so that it becomes clear that IRIs are allowed.


That being said, I just tested IRIs with IE/FF/Opera/Safari, and they 
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have 
any kind of interoperability here.


BR, Julian


(*) For the non-ASCII characters in the IRI (reference) /äöü.html, IE 
sends the raw (ISO8859-1) encoded bytes.

IRI support in XHR, was: XHR LC comments

[Julian Reschke]

Julian Reschke wrote:
That being said, I just tested IRIs with IE/FF/Opera/Safari, and they 
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have 
any kind of interoperability here.


...so this should probably be covered by the test suite...

BR, Julian

Re: IRI support in XHR, was: XHR LC comments

[Anne van Kesteren]

On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke [EMAIL PROTECTED]  
wrote:

Julian Reschke wrote:
That being said, I just tested IRIs with IE/FF/Opera/Safari, and they  
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't  
have any kind of interoperability here.


3/4 doing the same sounds like interoperability is pretty good. There are  
features discovered where there's 6/4 having different behavior.  
(Different versions of the same engine.)




...so this should probably be covered by the test suite...


Of course, everything should.


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

Re: IRI support in XHR, was: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:


On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke 
[EMAIL PROTECTED] wrote:

Julian Reschke wrote:
That being said, I just tested IRIs with IE/FF/Opera/Safari, and they 
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't 
have any kind of interoperability here.


3/4 doing the same sounds like interoperability is pretty good. There 
are features discovered where there's 6/4 having different behavior. 
(Different versions of the same engine.)


Of course 3/4 sounds better than less than half of the browsers in use 
:-).


Do you really believe anybody is going to use IRIs in XHR if there's no 
way to make it work in IE?



...so this should probably be covered by the test suite...


Of course, everything should.


I was mentioning it because MS apparently *does* run the test suite, so 
adding a test would help ensure the problem appears on their radar.


BR, Julian

Re: IRI support in XHR, was: XHR LC comments

[Anne van Kesteren]

On Wed, 18 Jun 2008 11:51:15 +0200, Julian Reschke [EMAIL PROTECTED]  
wrote:
Do you really believe anybody is going to use IRIs in XHR if there's no  
way to make it work in IE?


3/4 means it's not a Web compatibility problem to support them. No idea  
what authors will do in the near future.




...so this should probably be covered by the test suite...

 Of course, everything should.


I was mentioning it because MS apparently *does* run the test suite, so  
adding a test would help ensure the problem appears on their radar.


I failed adding a non-ASCII file name through subversion to  
tc.labs.opera.com so I guess that has to wait until we move the test suite  
somewhere else. (I tested IRC support somewhere else.)



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

Re: IRI support in XHR, was: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:
I was mentioning it because MS apparently *does* run the test suite, 
so adding a test would help ensure the problem appears on their radar.


I failed adding a non-ASCII file name through subversion to 
tc.labs.opera.com so I guess that has to wait until we move the test 
suite somewhere else. (I tested IRC support somewhere else.)


In my test (with Apache) I didn't even create the file. I get 404 when 
invoking GET on a properly encoded IRI, a 403 when the URL on the wire 
was malformed (as for IE). Maybe that's sufficient for a test.


BR, Julian

Re: IRI support in XHR, was: XHR LC comments

[Alexey Proskuryakov]

On Jun 18, 2008, at 1:56 PM, Anne van Kesteren wrote:

I failed adding a non-ASCII file name through subversion to  
tc.labs.opera.com so I guess that has to wait until we move the test  
suite somewhere else. (I tested IRC support somewhere else.)



Here is a similar test we have in WebKit, and which doesn't need files  
with non-ASCII file names: http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/utf8-path.html 
, http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/intercept/.htaccess 
.


- WBR, Alexey Proskuryakov

[XHR] (Late) LC Comments

[Geoffrey Sneddon]

Lazy me has finally got around to sending some comments:

Under the definition of XML response entity body it is probably worth  
reiterating that if the UA is not also a conforming XML UA it must  
return null.


getAllResponseHeaders() should probably define the exact format. The  
example makes me think that it should always output one space (U+0020)  
after the colon, but currently anything is fine.


status and statusText currently MUST throw INVALID_STATE_ERR when  
there isn't any status code or text respectively sent by the server.  
HTTP/0.9 includes neither: Saf, Fx, and IE all return 200 and OK,  
and Op returns 0 and . There isn't actually any issue with the  
state, so throwing an INVALID_STATE_ERR makes little sense. Also, a  
fair number of servers manage to omit the statusText, and that should  
just return OK (per Saf, Fx, and IE). I'd say that it should only  
throw if the state is UNSENT or OPENED.


In Exceptions for the XMLHttpRequest Object it would be nice to have  
a note that the other exceptions are defined in DOM 3 Core.



--
Geoffrey Sneddon
http://gsnedders.com/

LC comments.

[Yves Lafon]

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

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

In 4:
*

If stored method case-insensitively matches CONNECT, DELETE, GET, HEAD, 
OPTIONS POST, PUT, TRACE, or TRACK let stored method be the canonical 
uppercase form of the matched method name.



TRACK ??? Where is the reference to that?

*

14: If the user argument was not omitted and is not null let stored user 
be user encoded using the encoding specified in the relevant 
authentication scheme or UTF-8 if the scheme fails to specify an encoding.



(and same for point 17)

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

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

   Userids might be case sensitive.

and from rfc2616:
   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of RFC 2047
   [14].

   TEXT   = any OCTET except CTLs,
but including LWS

So UTF8 is not the encoding of choice, there.

*

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


* Accept-Charset
* Accept-Encoding
* Connection
* Content-Length
* Content-Transfer-Encoding
* Date
* Expect
* Host
* Keep-Alive
* Referer
* TE
* Trailer
* Transfer-Encoding
* Upgrade
* Via 



What is the rationale to add headers and not others ?
Connection ?
Accept-Charset ? 
For Host, Content-Length, TE... this should be set by the implementation 
anyway, overriding what a user might fill in, so why terminate the 
processing here ?


*

Also for security reasons, these steps should be terminated if the start 
of the header argument case-insensitively matches Proxy- or Sec-.


It would forbid other spec to do something fancy with Proxy-* or Sec-* 
headers, why ?


* in send()

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


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



Why not linking to those requirements ?

*

In case of DNS errors, or other type of network errors, run the following set 
of steps. This does not include HTTP responses that indicate some type of 
error, such as HTTP status code 410.
[...]


Some request may be retried, like GET, especially if the targeted web site 
resolves in a set of IP addresses and some of them may be down. It is 
unclear that the implementation will try its best to process the request, 
by retrying when needed, or if it is forbidden.


Cheers,

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

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

~~Yves

Re: XHR LC comments

[Anne van Kesteren]

On Tue, 27 May 2008 15:44:21 +0200, Julian Reschke [EMAIL PROTECTED]  
wrote:

Anne van Kesteren wrote:
On Tue, 27 May 2008 14:29:16 +0200, Julian Reschke  
[EMAIL PROTECTED] wrote:
You're still avoiding the question whether the URL parameter can be an  
IRI. I would assume it can't, in which case the spec should require it  
to conform to RFC3986.

 It can. I made the specification more clear on this.


- Is this actually implemented?


Yes. In Opera and Firefix it is, at least.


- If the URL parameter can be a IRI, then somewhere later on we need to  
state that it needs to be transformed to a URI before it's put on the  
wire.


Added a transformation step as per 3.1 and also required throwing a  
SYNTAX_ERR in case of failure (ToASCII operation failure seems the most  
likely).



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

Re: XHR LC comments

[Julian Reschke]

Julian Reschke wrote:

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


For the record, the HTTPbis WG discussed the issue of GET/HEAD with 
request bodies a few months ago, and the resolution was that in general 
they are allowed unless explicitly forbidden (which is not the case for 
GET or HEAD).


See http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19 and 
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-02.


BR, Julian

Re: XHR LC comments

[Julian Reschke]

Bjoern Hoehrmann wrote:

* Julian Reschke wrote:
- If the URL parameter can be a IRI, then somewhere later on we need to 
state that it needs to be transformed to a URI before it's put on the wire.


Actually that is for the HTTP specification to define, which right now
does so implicitly by allowing only URIs. Restating requirements usually
leads to specifications stating conflicting requirements, it's best not
done at all, except in informative notes clearly limited to the known
cases (e.g., Note: Because HTTP/1.0 and HTTP/1.1 allow only URIs as
request URIs, user agents will transform the IRI to an URI when creating
the request message., though I would not add this).


And HTTPbis is not going to change that, as referencing RFC3987 would be 
a downref.


XHR is defining an HTTP API. If that API allows IRIs where HTTP wants 
URIs, then I think it should be stated somewhere that a transformation 
needs to take place.


BR, Julian

setRequestHeader / Accept (was: Re: XHR LC comments)

[Anne van Kesteren]

On Thu, 15 May 2008 20:57:44 +0200, Laurens Holst  
[EMAIL PROTECTED] wrote:

When invoking request.setRequestHeader('Accept', ''):

- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: */*
- Safari 3.1.1 sends Accept:
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1


Per the specification Safari is conformant.



When invoking request.setRequestHeader('Accept', null):

- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: null
- Safari 3.1.1 sends Accept: null
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1


Per the updated specification which uses Web IDL IE and Safari are  
conformant here. (null and undefined are simply stringified.)


(That Firefox removes the Accept header is because it treats null the same  
as the empty string.)




I can’t believe how horribly broken this all is. No wonder few people
depend on this header. Fortunately, as a result it can also be fixed
without breaking much.


Yeah, if you set Accept through setRequestHeader() it should just work  
fine. If you don't the browser should provide it with a value of */*.


(The draft has not yet been updated because I'm still tweaking some bits  
with respect to Web IDL.)



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

Re: XHR LC comments

[Julian Reschke]

Julian Reschke wrote:

...
Currently there is no conversion, and what is specified clearly can 
cause implementations to create broken requests, where the code worked 
before.

...


...even without looking for it, I came across this one: 
https://jersey.dev.java.net/servlets/ReadMsg?list=usersmsgNo=1346. So 
please don't claim that this isn't a problem.


BR, Julian

Re: XHR LC comments

[Julian Reschke]

Bjoern Hoehrmann wrote:

* Boris Zbarsky wrote:

Bjoern Hoehrmann wrote:

Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in

Which you can, with a non-NS-aware XML parser.


My point was that the XHR draft currently requires using a namespace-
aware one, so for both writing and reading, you would have to change
two parts of the draft.


Bot sure. The recipient is a server which does not use XHR for parsing 
at all, right?



The problem is that figuring out whether a DOM fragment can usefully
be serialized as a ns-wellformed string is a bit of a pain.


Could you elaborate on this point? You need to serialize the document
before starting to send it, to ensure that changes to it do not affect
what is being sent, to set the Content-Length header, etc., and you
can rather easily check for ns-wf during serialization if you implement
the serialization yourself, so this does not seem like a problem. Even
if you cannot do it during serialization, the algorithm to do it on the
document object is relatively simple aswell.


You could implement a streaming serialization, in which case errors like 
these would only be catched when the response is already partly written 
(and no, you don't need the content length beforehand, you can always 
use Transfer-Encoding: chunked).


BR, Julian

Re: XHR LC comments

[Simon Pieters]

On Mon, 19 May 2008 05:07:52 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:

and you can rather easily check for ns-wf during serialization if you  
implement

the serialization yourself


Perhaps.  This is less clear to me.  In particular, it's not that clear  
to me that its trivial to decide whether a given DOM has a ns-wellformed  
serialization.  Certainly there have been a number of past bugs in the  
Gecko serializer dealing with this aspect of things, and I wouldn't bet  
my life on there not being any now.


FWIW, this is defined for getting innerHTML in XML:  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html#innerhtml1


Perhaps XHR should just reference that?

--
Simon Pieters
Opera Software

Re: XHR LC comments

[Bjoern Hoehrmann]

* Boris Zbarsky wrote:
On the server side?

No, I was simply trying to say XHR should not generate output it cannot
parse itself. Either it generates and parses a document, or it neither
generates nor parses a document. If there was a parameter to set, like
LSParser.domConfig.namespaces, to control this, that would be fine, but
I am not suggesting such an addition.

   var el = doc.createElementNS(ns1, x:y);
   el.setAttributeNS(ns2, x:z, val);

Here are the results I see:

   Firefox 3rc1:

 x:y xmlns:x=ns1 a0:z=val xmlns:a0=ns2/

   Opera 9.25:

 ?xml version=1.0?x:y x:z=val xmlns:x=ns1/

   Safari 3.1:

 x:y x:z=val /

Ignoring the Safari serialization, which is not in fact ns-wellformed no 
matter 
how you slice it, the other two are ns-wellformed XML.  Neither one roundtrips 
to quite the original document.  Which one is correct per the current spec? 

DOM Level 3 Core Appendix B.1 should define how to fix the tree. There
are some imperfections in the other namespace algorithms in the appendix
and it does not say how good the error reporting is, but I believe the
idea is that, either you get an error, or you can serialize the document
without special handling for namespaces. Above Opera's behavior is wrong
since you created an attribute in ns2 but now it's suddenly in ns1. Only
renameNode can cause that.

The behavior of Firefox seems correct to me, except that it does not use
the nsindex pattern to create the new prefix. You picked a document
that cannot exist when building it directly from a plain text document,
so that this does not very strictly speaking roundtrip does not seem an
issue to me.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · 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/ 

Re: XHR LC comments

[Boris Zbarsky]

Simon Pieters wrote:
FWIW, this is defined for getting innerHTML in XML: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html#innerhtml1 


That's more like what I was looking for, yes.  I would be happy if XHR adopted 
that approach.


-Boris

RE: XHR LC comments

[Sunava Dutta]

Inline...

 -Original Message-
 From: Anne van Kesteren [mailto:[EMAIL PROTECTED]
 Sent: Saturday, May 17, 2008 5:45 AM
 To: Julian Reschke
 Cc: Maciej Stachowiak; Sunava Dutta; Web API WG (public)
 Subject: Re: XHR LC comments

 On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke [EMAIL PROTECTED]
 wrote:
  Anne van Kesteren wrote:
  On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
  [EMAIL PROTECTED] wrote:
  But what IMHO happens all over again is that strange choices in the
  design are defended with the statement this is what the vendors do,
  or want to do, and when we check it, that turns out to be incorrect.
   Could you point out one such example? I've actually tested a fair
  amount
 
  They are in the current threads.
 
  - add semantics for setRequestHeader
  - semantics for setRequestHeader(...,null)
  - silent data loss for send() when DOM can't be serialized
  - ...

 I think only for the last one I have suggested that I rather not change it
 based on that this seems like a safer choice. I have not seen any tests
 that show that implementations actually throw in that case.


  of stuff, including headers, methods, etc. I agree that some of the
  details of headers need to be worked out. For null//undefined I've
  been waiting for the Web IDL specification. For which headers can be
  set by the user agent I don't really have an answer and that part has
  not been defined as such. That setRequestHeader() always appends was a
  conscious choice to be in line with Internet Explorer. Initially the
  design was so that it special cased a bunch of headers that did not
  allow duplication which would have been more in line with Firefox, but
  given that it is not a fixed list and the Internet Explorer route
  seemed more appropriate.
 
  Well, not to me. And apparently not to FF, as FF3 seems to ship with be
  non-compliant behavior.

 To my best knowledge Mozilla hasn't started implementing the specification
 yet. I've seen several comments in their public bug database to the effect
 that they rather wait until it reaches CR.


  setRequestHeader() currently simply is broken. We should deprecate it,
  and add new methods with well-defined semantics:
 
  - removeHeader(...) (or specify set with null to mean remove)
  - addHeader...
  - getHeader...

 Deprecating a method does not help implementations converge. Besides,
 for typical usage there's no issue in using this header at all.

[Sunava Dutta] I agree with Anne here. Deprecating an existing implementations 
and re-engineering XHR is something we just cannot accept. This spec should be 
designed to reflect reality and seek interoperability for each and every single 
section/method/event with at least one (I think the W3C mandates two?) existing 
implementations. That does not mean the entire spec is aligned with FF or IE, 
but it should be harmonious at any instance with one existing implementation.

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

Re: XHR LC comments

[Boris Zbarsky]

Sunava Dutta wrote:

I think you mean compatible with browsers who enable
the technologies when you mean compatible with the web?


Compatible with the web means that when a UA implements the specification as 
written it will encounter either no reports of pages broken due to that 
implementation or a very very small number of them.


One possible way to do that is to implement exactly what the market leader 
implements, although even that is no guarantee if sites work around some 
behavior of the market leader based on UA sniffing.


In reality, what's needed here is that all commonly used functionality (and 
yes, this is an imprecise term; so is compatible with the web in the end) is 
specified the way websites expect it to work.  Whether they expect it because of 
some other implementation, because of a popular book, because of documentation 
somewhere, or for some other reason is not relevant.  What's relevant is what 
they expect when they write their code.



I'm amenable to what Maciej
said when he mentioned that in the case (I'm assuming this is a rarity) where
the implementations are doing whacky things or doing nothing at all, it makes
sense to work together to identify a way/solution that will allow for
convergence.


Right.  Any time implementations disagree, the most likely conclusion is that 
the point on which they don't agree is not used much, if at all, by websites. 
Therefore the exact behavior the spec requires on that point doesn't affect the 
compatible with the web criterion.


-Boris

Re: XHR LC comments

[Jonas Sicking]

Sunava Dutta wrote:

Inline...


-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 3:14 PM
To: Sunava Dutta
Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
(public); IE8 Core AJAX SWAT Team
Subject: Re: XHR LC comments

Sunava Dutta wrote:

setRequestHeader() currently simply is broken. We should deprecate it,
and add new methods with well-defined semantics:

- removeHeader(...) (or specify set with null to mean remove)
- addHeader...
- getHeader...

Deprecating a method does not help implementations converge. Besides,
for typical usage there's no issue in using this header at all.


[Sunava Dutta] I agree with Anne here. Deprecating an existing
implementations and re-engineering XHR is something we just cannot
accept. This spec should be designed to reflect reality and seek
interoperability for each and every single section/method/event with
at least one (I think the W3C mandates two?) existing implementations.
That does not mean the entire spec is aligned with FF or IE, but it
should be harmonious at any instance with one existing implementation.

There is absolutely no W3C mandate that a spec is compatible with any
existing implementations in order to reach the earlier milestones in the
standardization track. Not sure where you got that idea. It would be
very strange if there was a requirement to have implementations in order
to reach LC, when W3C is discouraging implementations at that stage.

Also, I personally don't care at all which UAs the various features of
spec is compatible with. Or if it's not compatible with any UA. What I
care about is that the spec is compatible with the web, and in the cases
where the web doesn't care, that it's as useful and simple as possible.

/ Jonas

[Sunava Dutta] Compatible with the web sounds very nice and is
something I think I share with you. I think you mean compatible with
browsers who enable the technologies when you mean compatible with the
web?


No, I mean able to run the javascript that exists on pages on the web. 
So for example if there is an aspect to a feature that no, or very few, 
web pages use, then I don't think we need to pay attention to what UAs 
do today and instead make the best possible spec based on technical 
considerations.


Figuring out what aspects webpages do or don't use is hard of course. 
But often there are indications as well as implementation experience.



Getting back to more specifics, if we're talking about compatibility I
absolutely believe the spec should be relevant to existing
implementations.


What do you mean by relevant to existing implementations. And why do 
you think that?



I'm amenable to what Maciej said when he mentioned
that in the case (I'm assuming this is a rarity) where the
implementations are doing whacky things or doing nothing at all, it
makes sense to work together to identify a way/solution that will
allow for convergence.


It is in fact quite common when you start looking at the details of the 
various features that implementations behave very differently. So in 
those details we should in my opinion use the strategy I described above.


/ Jonas

RE: XHR LC comments

[Sunava Dutta]

Inline...

 -Original Message-
 From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
 Sent: Saturday, May 17, 2008 2:04 AM
 To: Julian Reschke
 Cc: Sunava Dutta; Anne van Kesteren; Web API WG (public)
 Subject: Re: XHR LC comments


 On May 17, 2008, at 1:03 AM, Julian Reschke wrote:

 
  Sunava Dutta wrote:
  ...
  At this point, I'm not sure why we're bothering with XHR1 at all.
  It is
  *not* what the current implementations do anyway.
  [Sunava Dutta] I'm sorry, this statement is concerning and I'd like
  to understand it better. We haven't had a chance to run the latest
  test suite yet but expect the test suite to be compliant with at
  least two existing implementations. Do you mean the XHR 1 draft is
  not interoperable with existing implementations?
  ...
 
  Absolutely. Everytime I check something that is of interest to me it
  turns out that there is no interop, and that only some or even none
  of the browsers works as specified.

 We decided long ago (and subsequently reaffirmed) that instead of
 leaving the spec so vague that all existing implementations are
 automatically compliant, we would define a shared interoperable
 behavior so that implementations can converge. It should not be news
 to anyone that implementations are not automatically 100% compliant.

  Examples:
 
  - Support for HTTP extension methods: IE violates the SHOULD level
  requirement to support extenstion methods. Opera silently (!!!)
  changes extension method names to POST.
 
  - setRequestHeader: none of the browsers throws an exception when
  setting the header to null. Some do something useful (removing the
  header), some treat it like an empty string, some seem to set the
  valoue to the string null.
 
  I'm also concerned that the spec proposes behaviour that leads to
  silent data loss, although it's totally unclear why this is needed
  for interoperability (such as when a DOM to be serialized has no XML
  representation).
 
  It seems that what's needed here is more work on the test suite. LC
  is way too early.

 By W3C Process, the test suite is supposed to be developed during the
 CR period. So by having one at all before LC, we are ahead of schedule.

[Sunava Dutta] Can I have a link to this? I can't find it. Thanks!
Btw, we discussed the possibility of having the test suite ready before CR (see 
below). I think that's wise given that you mentioned that there are many cases 
where interoperability has not been reached? (or a convergence plan is not in 
place?) Our XHR test is going to be running the test suite in LC to see where 
interop doesn't exist and weigh in with our thoughts where we can to help.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0019.html
In response to our mail:
 2) In fact, on that note, we're interested to see the test suite be
 linked, normatively if necessary.
Charles said
Yes. I think this is a valuable piece of feedback. Currently W3C process
doesn't require test suites until you're trying to get out of CR and I
think it would be better to have them earlier. I would
like the group to start checking the test cases we have against the spec
and formally agreeing them to facilitate this linkage during last call. It
slows down the LC period, but it should make CR easier and reduce the
possibility of reverting from CR.

)


 Regards,
 Maciej

Re: XHR LC comments

[Boris Zbarsky]

Julian Reschke wrote:

For this one I used Dom L1 methods to create this document:

  foox:y//foo

which isn't XMLNS-wellformed.


I'm not sure I see the problem here, to be honest...  Using the 
non-namespace-aware DOM methods one can indeed create documents that require a 
non-namespace-aware XML parser to roundtrip.


Since the UA has no idea what sort of XML parser is being used on the server 
side, I'm not sure it makes sense to bail on attempts to serialize such 
documents.  In particular, if the document _is_ parsed with a 
non-namespace-aware XML parser, there is no problem.


-Boris

Re: XHR LC comments

[Boris Zbarsky]

Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the 
server side, I'm not sure it makes sense to bail on attempts to 
serialize such documents.  In particular, if the document _is_ parsed 
with a non-namespace-aware XML parser, there is no problem.


That's true. But it's not what the XHR spec requires:

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. -- 
http://dev.w3.org/2006/webapi/XMLHttpRequest/#send


So the spec requires silent data loss here, which I think is an 
extremely bad idea.


Agreed.  I think the spec needs changing to allow this use case, personally...

-Boris

Re: XHR LC comments

[Julian Reschke]

Boris Zbarsky wrote:

Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the 
server side, I'm not sure it makes sense to bail on attempts to 
serialize such documents.  In particular, if the document _is_ parsed 
with a non-namespace-aware XML parser, there is no problem.


That's true. But it's not what the XHR spec requires:

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. -- 
http://dev.w3.org/2006/webapi/XMLHttpRequest/#send


So the spec requires silent data loss here, which I think is an 
extremely bad idea.


Agreed.  I think the spec needs changing to allow this use case, 
personally...


I think it should say that if the DOM can't be serialized, an exception 
needs to be thrown.


Not sure whether it makes sense to allow non-XMLNS-compliant 
serializations, though.


BR, Julian

Re: XHR LC comments

[Boris Zbarsky]

Bjoern Hoehrmann wrote:

Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in


Which you can, with a non-NS-aware XML parser.


and the odds that some
wf-but-ns-illformed has been created deliberately for use with XHR
as opposed to being created due to some mistake, seem too low to make
supporting this worthwhile.


The problem is that figuring out whether a DOM fragment can usefully be 
serialized as a ns-wellformed string is a bit of a pain.  I have no faith in the 
spec being interoperably implemented as written.


-Boris

Re: XHR LC comments

[Bjoern Hoehrmann]

* Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
 Being able to send wf-but-ns-illformed documents would not make much
 sense if you couldn't also read them back in

Which you can, with a non-NS-aware XML parser.

My point was that the XHR draft currently requires using a namespace-
aware one, so for both writing and reading, you would have to change
two parts of the draft.

The problem is that figuring out whether a DOM fragment can usefully
be serialized as a ns-wellformed string is a bit of a pain.

Could you elaborate on this point? You need to serialize the document
before starting to send it, to ensure that changes to it do not affect
what is being sent, to set the Content-Length header, etc., and you
can rather easily check for ns-wf during serialization if you implement
the serialization yourself, so this does not seem like a problem. Even
if you cannot do it during serialization, the algorithm to do it on the
document object is relatively simple aswell.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · 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/ 

Re: XHR LC comments

[Maciej Stachowiak]

On May 17, 2008, at 1:03 AM, Julian Reschke wrote:



Sunava Dutta wrote:

...
At this point, I'm not sure why we're bothering with XHR1 at all.  
It is

*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like  
to understand it better. We haven’t had a chance to run the latest  
test suite yet but expect the test suite to be compliant with at  
least two existing implementations. Do you mean the XHR 1 draft is  
not interoperable with existing implementations?

...


Absolutely. Everytime I check something that is of interest to me it  
turns out that there is no interop, and that only some or even none  
of the browsers works as specified.


We decided long ago (and subsequently reaffirmed) that instead of  
leaving the spec so vague that all existing implementations are  
automatically compliant, we would define a shared interoperable  
behavior so that implementations can converge. It should not be news  
to anyone that implementations are not automatically 100% compliant.



Examples:

- Support for HTTP extension methods: IE violates the SHOULD level  
requirement to support extenstion methods. Opera silently (!!!)  
changes extension method names to POST.


- setRequestHeader: none of the browsers throws an exception when  
setting the header to null. Some do something useful (removing the  
header), some treat it like an empty string, some seem to set the  
valoue to the string null.


I'm also concerned that the spec proposes behaviour that leads to  
silent data loss, although it's totally unclear why this is needed  
for interoperability (such as when a DOM to be serialized has no XML  
representation).


It seems that what's needed here is more work on the test suite. LC  
is way too early.


By W3C Process, the test suite is supposed to be developed during the  
CR period. So by having one at all before LC, we are ahead of schedule.


Regards,
Maciej

Re: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke 
[EMAIL PROTECTED] wrote:
But what IMHO happens all over again is that strange choices in the 
design are defended with the statement this is what the vendors do, 
or want to do, and when we check it, that turns out to be incorrect.


Could you point out one such example? I've actually tested a fair amount 


They are in the current threads.

- add semantics for setRequestHeader
- semantics for setRequestHeader(...,null)
- silent data loss for send() when DOM can't be serialized
- ...

of stuff, including headers, methods, etc. I agree that some of the 
details of headers need to be worked out. For null//undefined I've 
been waiting for the Web IDL specification. For which headers can be set 
by the user agent I don't really have an answer and that part has not 
been defined as such. That setRequestHeader() always appends was a 
conscious choice to be in line with Internet Explorer. Initially the 
design was so that it special cased a bunch of headers that did not 
allow duplication which would have been more in line with Firefox, but 
given that it is not a fixed list and the Internet Explorer route seemed 
more appropriate.


Well, not to me. And apparently not to FF, as FF3 seems to ship with be 
non-compliant behavior.


setRequestHeader() currently simply is broken. We should deprecate it, 
and add new methods with well-defined semantics:


- removeHeader(...) (or specify set with null to mean remove)
- addHeader...
- getHeader...

BR, Julian

Re: XHR LC comments

[Anne van Kesteren]

On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke [EMAIL PROTECTED]  
wrote:

Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke  
[EMAIL PROTECTED] wrote:
But what IMHO happens all over again is that strange choices in the  
design are defended with the statement this is what the vendors do,  
or want to do, and when we check it, that turns out to be incorrect.
 Could you point out one such example? I've actually tested a fair  
amount


They are in the current threads.

- add semantics for setRequestHeader
- semantics for setRequestHeader(...,null)
- silent data loss for send() when DOM can't be serialized
- ...


I think only for the last one I have suggested that I rather not change it  
based on that this seems like a safer choice. I have not seen any tests  
that show that implementations actually throw in that case.



of stuff, including headers, methods, etc. I agree that some of the  
details of headers need to be worked out. For null//undefined I've  
been waiting for the Web IDL specification. For which headers can be  
set by the user agent I don't really have an answer and that part has  
not been defined as such. That setRequestHeader() always appends was a  
conscious choice to be in line with Internet Explorer. Initially the  
design was so that it special cased a bunch of headers that did not  
allow duplication which would have been more in line with Firefox, but  
given that it is not a fixed list and the Internet Explorer route  
seemed more appropriate.


Well, not to me. And apparently not to FF, as FF3 seems to ship with be  
non-compliant behavior.


To my best knowledge Mozilla hasn't started implementing the specification  
yet. I've seen several comments in their public bug database to the effect  
that they rather wait until it reaches CR.



setRequestHeader() currently simply is broken. We should deprecate it,  
and add new methods with well-defined semantics:


- removeHeader(...) (or specify set with null to mean remove)
- addHeader...
- getHeader...


Deprecating a method does not help implementations converge. Besides,  
for typical usage there's no issue in using this header at all.



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

Re: XHR LC comments

[Julian Reschke]

Julian Reschke wrote:

...
Data loss is not a safe choice, it's a bad choice.

Do you have any evidence of deployed code that would break if this would 
throw?

...


I just tried with FF3 and IE7.

Using a non-ns-wellformed document:

- FF3: happily sends it
- IE7: couldn't figure out how to create it (respect!)

Using an document that has no root element, but a single comment:

- FF3: happily sends it
- IE7: throws an exception

So, how is data loss a safe choice here???

BR, Julian

Re: XHR LC comments

[Julian Reschke]

Julian Reschke wrote:

Boris Zbarsky wrote:

Julian Reschke wrote:

Using a non-ns-wellformed document:

- FF3: happily sends it


Out of curiosity, what did this document look like?  What got sent?


I removed the document element and added a comment node, so it looked like:

  !-- foo --


Sorry, that was the other case.

For this one I used Dom L1 methods to create this document:

  foox:y//foo

which isn't XMLNS-wellformed.

BR, Julian

Re: XHR LC comments

[Julian Reschke]

Ian Hickson wrote:
...in which case I'd say that (a) the references aren't normative after 
all, and (b) the spec itself can't be normative as it is written.


I don't mind calling the references informative if that's what it takes. 
I'm not sure what practical difference it would make.


You can't make them informative by just saying so. The question is, do I 
need material from HTML5 to implement a conforming XHR implementation? 
If yes, then XHR can't be published earlier. If no, let's rephrase stuff 
so that HTML5 isn't required.


practice, take anything away from the ability to get interoperable 
implemenations of the feature described in XHR1.

Really?

What if Apple implements the thing as defined by HTML5-as-of-2008, and 
Microsoft as defined in HTML5-as-of-2009?


If it matters, then it's a problem. If it doesn't matter, leave it out 
of the XHR spec, as apparently, it's irrelevant for the goal it's trying 
to achieve.


The point is that Apple and Microsoft are both going to implement the 
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is 
describing existing practice on these matters, not defining new material. 


Well, in that case pull that stuff out of HTML5 and insert it into the 
XHR spec (or move it into something that can be published separately).


BR, Julian

Re: XHR LC comments

[Anne van Kesteren]

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 maybe  
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  
surehow 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;


Since this is the second Last Call and credentials are already following  
each other (and the same for other similar steps) I've decided not to  
change this.



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  
thatentire section editorially as it might introduce new errors.


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


Given that XMLHttpRequest Level 2 has more changes than just this in terms  
of structure I don't think it will help that much.



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.


Changed:

  http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies



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


Ok, referenced RFC3986 as well.


Besides that: this may be a non-optimal example unless we can point  
toa 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?


I added a pointer to http://msdn.microsoft.com/en-us/library/ms533046.aspx



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.


I added a note.


If the user argument was not omitted and is not null let stored  
userbe 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  
stringor 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.


Actually, since you need to encode them for the request it does.


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


I added a note to that effect as it is already normatively required.


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


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


I don't know, but it seems safest to not require changes here for  
compatibility.



If no Content-Type header has been set using setRequestHeader()append  
a Content-Type header to the list of request headers with avalue of  
application/xml;charset=charset  where charset is theencoding 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  
speccurrently allows; and at least one UA was reported to do). See  
commentabove about header handling.

Rephrased.


Pointer?


  http://dev.w3.org/2006/webapi/XMLHttpRequest/#send


If the user agent supports HTTP State Management it should persist, 
discard and send cookies (as received in the Set-Cookie andSet-Cookie2  
response headers, and sent in the Cookie header) asapplicable.  
[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 

Re: XHR LC comments

[Julian Reschke]

Anne van Kesteren wrote:
Since this is the second Last Call and credentials are already following 
each other (and the same for other similar steps) I've decided not to 
change this.


Unfortunately.

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


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


Given that XMLHttpRequest Level 2 has more changes than just this in 
terms of structure I don't think it will help that much.


At this point, I'm not sure why we're bothering with XHR1 at all. It is 
*not* what the current implementations do anyway.


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


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


Changed:

  http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies


Thanks.


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


Ok, referenced RFC3986 as well.


That's not sufficient, and not what I asked for. Please make up your 
mind whether it's a URI or a IRI, and then cite accordingly.


Besides that: this may be a non-optimal example unless we can point 
toa definition of HttpOnly cookies. Can we?
I don't believe we can, but since this was put in mostly for 
HttpOnlycookies I rather not remove that. I think it will be clear 
enough forpeople 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?


I added a pointer to http://msdn.microsoft.com/en-us/library/ms533046.aspx


Thanks.




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.


I added a note.


I'd prefer it to be moved somewhere else, but at least it's an improvement.


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


Actually, since you need to encode them for the request it does.


But that totally depends on the authentication scheme. I think you're 
confusing layers here.



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.


I added a note to that effect as it is already normatively required.


Thanks. It currently says:

Note: The empty string is legal.

Maybe you could add and represent an empty header value?

Serialize data into a namespace well-formed XML document and 
encodedusing the encoding given by data.inputEncoding, when not 
null, orUTF-8 otherwise. Or, if this fails because the Document 
cannot beserialized act as if data  is null.


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


I don't know, but it seems safest to not require changes here for 
compatibility.


Sounds like something that should be tested. Silent data loss is a bad 
thing, and I really don't believe that any existing content relies on that.


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


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

Rephrased.


Pointer?


  http://dev.w3.org/2006/webapi/XMLHttpRequest/#send


So is it legal for implementations to populate certain headers upon 
object creation?


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


This should probably include a reference to the Set-Cookie 
(notSet-Cookie2) spec as well (RFC2109).
I believe it used to do that and it was pointed out that 
thatspecification is not useful in practice and would actually do 
more harmthan 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.


Ok done.


Thanks.


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

Re: XHR LC comments

[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

Re: XHR LC comments

[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

Re: XHR LC comments

[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.   `._.-(,_..'--(,_..'`-.;.'

Re: XHR LC comments

[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

Re: XHR LC comments

[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.   `._.-(,_..'--(,_..'`-.;.'

Re: XHR LC comments

[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.   `._.-(,_..'--(,_..'`-.;.'

Re: XHR LC comments

[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

Re: XHR LC comments

[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.   `._.-(,_..'--(,_..'`-.;.'

Re: XHR LC comments

[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

Re: XHR LC comments

[Julian Reschke]

Ian Hickson wrote:

...
What's wrong with referencing HTML5? Why can't the spec be more ready than 
its normative references? We're only really referencing the concept, the 
details aren't particularly critical to XHR.

...


Because, by definition, normative references are part of the specification.

Sorry, don't know how to make that more clear.

BR, Julian

Re: XHR LC comments

[Julian Reschke]

Laurens Holst wrote:

Julian Reschke schreef:

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.


When invoking request.setRequestHeader('Accept', ''):


Laurens, thanks a *lot* for testing this.


- Firefox 3b5 removes the Accept header


Ouch. Has this been raised as a bug yet?


- Internet Explorer 8 (in IE7 mode) sends Accept: */*


Ouch. Has this been raised as a bug yet?


- Safari 3.1.1 sends Accept:


Good.

- Opera 9.24 sends Accept: text/html, application/xml;q=0.9, 
application/xhtml+xml, image/png, image/jpeg, image/gif, 
image/x-xbitmap, */*;q=0.1


Not good.


When invoking request.setRequestHeader('Accept', null):

- Firefox 3b5 removes the Accept header


Makes sense, but isn't what XHR1 requires.


- Internet Explorer 8 (in IE7 mode) sends Accept: null


You really mean the four characters n-u-l-l? Ouch,


- Safari 3.1.1 sends Accept: null
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9, 
application/xhtml+xml, image/png, image/jpeg, image/gif, 
image/x-xbitmap, */*;q=0.1


I notice that none of the browsers does what XHR1 requires, but at least 
*one* (FF) does something useful.


So it is clear that here, too, browsers are in great disagreement. I am 
not sure what the correct approach here is, though '' meaning setting 
“Accept” and null meaning removal of the header sounds sensible.


Note by the way that Opera always prepends the set Accept header to its 
default value, resulting in e.g. Accept: */*, text/html, 
application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, 
image/gif, image/x-xbitmap, */*;q=0.1 when invoking 
request.setRequestHeader('Accept', null);


That should be considered a bug.

I can’t believe how horribly broken this all is. No wonder few people 
depend on this header. Fortunately, as a result it can also be fixed 
without breaking much.


I’ve also posted these results at http://www.grauw.nl/blog/entry/470 , 
the page source contains a test case.


BR, Julian

Re: XHR LC comments

[Julian Reschke]

Laurens Holst wrote:
 Julian Reschke schreef:
 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.


 When invoking request.setRequestHeader('Accept', ''):

Laurens, thanks a *lot* for testing this.

 - Firefox 3b5 removes the Accept header

Ouch. Has this been raised as a bug yet?

 - Internet Explorer 8 (in IE7 mode) sends Accept: */*

Ouch. Has this been raised as a bug yet?

 - Safari 3.1.1 sends Accept:

Good.

 - Opera 9.24 sends Accept: text/html, application/xml;q=0.9, 
application/xhtml+xml, image/png, image/jpeg, image/gif, 
image/x-xbitmap, */*;q=0.1


Not good.

 When invoking request.setRequestHeader('Accept', null):

 - Firefox 3b5 removes the Accept header

Makes sense, but isn't what XHR1 requires.

 - Internet Explorer 8 (in IE7 mode) sends Accept: null

You really mean the four characters n-u-l-l? Ouch,

 - Safari 3.1.1 sends Accept: null
 - Opera 9.24 sends Accept: text/html, application/xml;q=0.9, 
application/xhtml+xml, image/png, image/jpeg, image/gif, 
image/x-xbitmap, */*;q=0.1


I notice that none of the browsers does what XHR1 requires, but at least 
*one* (FF) does something useful.


 So it is clear that here, too, browsers are in great disagreement. I 
am not sure what the correct approach here is, though '' meaning setting 
“Accept” and null meaning removal of the header sounds sensible.


 Note by the way that Opera always prepends the set Accept header to 
its default value, resulting in e.g. Accept: */*, text/html, 
application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, 
image/gif, image/x-xbitmap, */*;q=0.1 when invoking 
request.setRequestHeader('Accept', null);


That should be considered a bug.

 I can’t believe how horribly broken this all is. No wonder few people 
depend on this header. Fortunately, as a result it can also be fixed 
without breaking much.


Also, this shows that it's *not* a good idea to just document what the 
vendors happen to come up with.


 I’ve also posted these results at http://www.grauw.nl/blog/entry/470 
, the page source contains a test case.


BR, Julian

Re: XHR LC comments

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:
 Ian Hickson wrote:
  ...
  What's wrong with referencing HTML5? Why can't the spec be more ready than
  its normative references? We're only really referencing the concept, the
  details aren't particularly critical to XHR.
  ...
 
 Because, by definition, normative references are part of the 
 specification.

But we don't have to limit ourselves to that definition. We could just as 
easily say that XHR1's functionality is as defined in XHR1, and that it 
uses terms and features that are currently underdefined. It wouldn't, in 
practice, take anything away from the ability to get interoperable 
implemenations of the feature described in XHR1.

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

Re: XHR LC comments

[Ian Hickson]

On Thu, 15 May 2008, Julian Reschke wrote:
  
  But we don't have to limit ourselves to that definition. We could just 
  as easily say that XHR1's functionality is as defined in XHR1, and 
  that it uses terms and features that are currently underdefined. It 
  wouldn't, in
 
 ...in which case I'd say that (a) the references aren't normative after 
 all, and (b) the spec itself can't be normative as it is written.

I don't mind calling the references informative if that's what it takes. 
I'm not sure what practical difference it would make.

  practice, take anything away from the ability to get interoperable 
  implemenations of the feature described in XHR1.
 
 Really?
 
 What if Apple implements the thing as defined by HTML5-as-of-2008, and 
 Microsoft as defined in HTML5-as-of-2009?
 
 If it matters, then it's a problem. If it doesn't matter, leave it out 
 of the XHR spec, as apparently, it's irrelevant for the goal it's trying 
 to achieve.

The point is that Apple and Microsoft are both going to implement the 
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is 
describing existing practice on these matters, not defining new material. 

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

RE: XHR LC comments

[Travis Leithead]

The point is that Apple and Microsoft are both going to implement the
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is
describing existing practice on these matters, not defining new material.

Well, a _few_ bits of new material ;-)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, May 15, 2008 1:35 PM
To: Julian Reschke
Cc: Anne van Kesteren; public-webapi@w3.org
Subject: Re: XHR LC comments


On Thu, 15 May 2008, Julian Reschke wrote:
 
  But we don't have to limit ourselves to that definition. We could just
  as easily say that XHR1's functionality is as defined in XHR1, and
  that it uses terms and features that are currently underdefined. It
  wouldn't, in

 ...in which case I'd say that (a) the references aren't normative after
 all, and (b) the spec itself can't be normative as it is written.

I don't mind calling the references informative if that's what it takes.
I'm not sure what practical difference it would make.

  practice, take anything away from the ability to get interoperable
  implemenations of the feature described in XHR1.

 Really?

 What if Apple implements the thing as defined by HTML5-as-of-2008, and
 Microsoft as defined in HTML5-as-of-2009?

 If it matters, then it's a problem. If it doesn't matter, leave it out
 of the XHR spec, as apparently, it's irrelevant for the goal it's trying
 to achieve.

The point is that Apple and Microsoft are both going to implement the
thing as required by the Web in 2000, not as defined in HTML5. HTML5 is
describing existing practice on these matters, not defining new material.

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

Re: XHR LC comments

[Maciej Stachowiak]

On May 15, 2008, at 1:24 PM, Julian Reschke wrote:



practice, take anything away from the ability to get interoperable  
implemenations of the feature described in XHR1.


Really?

What if Apple implements the thing as defined by HTML5-as-of-2008,  
and Microsoft as defined in HTML5-as-of-2009?


If it matters, then it's a problem. If it doesn't matter, leave it  
out of the XHR spec, as apparently, it's irrelevant for the goal  
it's trying to achieve.


In practice it is much more important for same-origin to be  
implemented consistently between XHR and HTML5 (and other Web  
standards) than for it to be precisely consistent cross-browser, as  
inconsistencies in the same-origin policy could lead to security  
holes. Thus, taking a snapshot of what HTML5 says and putting it in  
XHR1 would be a dead letter, because if HTML5 changes and browsers  
change to match it, they will not leave their XHR implementation using  
an older version of the security policy.


Regards,
Maciej

RE: XHR LC comments

[Ian Hickson]

On Thu, 15 May 2008, Travis Leithead wrote:
 
 The point is that Apple and Microsoft are both going to implement the 
 thing as required by the Web in 2000, not as defined in HTML5. HTML5 is 
 describing existing practice on these matters, not defining new 
 material.
 
 Well, a _few_ bits of new material ;-)

The bits that XHR depend on, which is the subject at hand, aren't new 
relative to the Web in 2000.

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

Re: XHR LC comments

[Anne van Kesteren]

On Sun, 04 May 2008 11:47:13 +0200, Julian Reschke [EMAIL PROTECTED]  
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
  

RE: XHR LC comments

[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:[EMAIL PROTECTED]
Sent: Tuesday, May 06, 2008 12:34 AM
To: Sunava Dutta
Cc: public-webapi@w3.org; 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

RE: XHR LC comments

[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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julian Reschke
Sent: Sunday, May 04, 2008 2:47 AM
To: public-webapi@w3.org
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