WebAPI Working Group F2F
22 Feb 2006


Robin, Charles, Stephane, Jonas, Anne, Dean, Ian, Gorm, Jim
Robin Berjon
Jonas, iand


Being public

RESOLUTION: we keep the log members only, then chair will send minutes to the public list after editing potential private stuff

which public list ?

RESOLUTION: work in public on the list we have, if it doesn't work return back to the member list or create a second public list read-only by public (they can always reply to the first public one)

<dino> ACTION: Dean to make new issues public and track them - due Friday

<trackbot> Created ACTION-47 - make new issues public and track them [on Dean Jackson - due 2006-02-24].

RESOLUTION: This groups tries to do all its work in public. New issues are sent to the public list and discussed there, unless there are any member-confidential msgs (they are sent to the member list).

Chairing Workload

RESOLUTION: CMN elected co-chair for Web APIs WG

coffee break

XmlHTTPRequest issues

JS: the list of XHR issues in moz bugzilla is too long to go through right now

RB: we don't need to have all issues resolved before publishing first draft
... Gorm wonders how do we relate to DOM3 L&S

JL: we should not relate to dOM3 L&S

JS: How do you do save in browsers

<darobin> http://www.w3.org/TR/DOM-Level-3-LS/load-save.html

GE: you could save to just a js-object with the appropriate properties according OutputStream interface

<darobin> http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSOutput

RB: it's LSOutput

<mjs> you can use xmlhttprequest with put or post

<mjs> and you can provide a document or dom node for the body data, it gets serialized

<mjs> (not sure if that is relevant to what y'all are talking about)

JS: the big part of the LS spec seems to me all the different configurations for entity expansion and such

<anne> (it was about how XMLHttpRequest is related to L&S)

JS: do we all agree to not relate to L&S?

<dino> GE: LS spec has a progress event, which may be useful

<bjoern> http://lists.w3.org/Archives/Public/www-dom/2005AprJun/0039.html (XmlHttpRequest and DOM 3 LS, Philippe Le Hegaret)

<dino> RB: Only for parsing, not download.

<mjs> XHR is simpler than LS but also has some extra capabilities that LS doesn't

<mjs> (specifically http protocol level stuff)

AK: Bjoern said he wanted to do errata for L&S at some point

RB: we can do errata separatly without relating XHR to it

JL: I've not seen anyone use it outside aside from test suits

RESOLUTION: Don't mention L&S in the XHR spec

<mjs> it might be worth mentioning how it is different

RB: what do we want in the XHR draft

<mjs> "no relationship" is sometimes a worthwhile thing to mention for "Relationships to other specs"

RB: on* properties are suboptimal

GE: but we'll have to live with it

<mjs> I don't think saying "there is no relationship" would confuse people

AK: should we put onload on the XHR interface, or on some more generic interface that is shared with for example <iframe> elements

<mjs> XHR shouldn't attempt to share interfaces with the HTML DOM

GE: ontimeout would be good to have

JL: IE goes into "complete" state and throws some HTTP code in the 50000s
... I don't think we need to add 'onload', people can use readystatechange

JS: would onload work in IE?

JL: no

RB: if we start deviating from IEs interface we might as well redesign from scratch

<mjs> Safari has onload on XHR, we probably copied it from mozilla

RB: I don't think we want to have a generic interface where we have onload

JL: we should not add any features that can't be detected if they exist or not from script. The support for onload can't be detected and therefor not reliably use

ID: i think the initial spec should be as small as possible and just define what is cross UA today

<mjs> onload is already implemented in more than one UA, it could be stated as an OPTIONAL level req

GE: opera always try to parse as XML

JL: depending on various configurations, the mimetype, and some other things, it'll try to parse as XML
... and it sniffs the content

CN: MS suggests OPTIONAL

AK: even if we declare stuff as OPTIONAL we still have to work out exactly how they work. Like does illformed xml still fire onload?

CN: another option is to put out a NOTE with "Things that we didn't do"

<mjs> XHR is often used to load non-xml resources as text

<mjs> note responseText property

<mjs> so probably onload should fire if and only if onreadystatechange fires with the final readyState

JL: a note with "these things have implementations in various UAs"

<anne> mjs, that might violate DOM Level 3 Events regarding 'load'...

JL: ...could be useful

<anne> mjs, better to work out later things that IE doesn't even support

<darobin> ACTION: GE to draft text for XHR listing commonly implemented properties and methods that we don't specify

<trackbot> Created ACTION-48 - Draft text for XHR listing commonly implemented properties and methods that we don\'t specify [on Gorm Haug Eriksen - due 2006-03-01].

<mjs> anne, sites could be using it because they often have dual IE / Moz code paths, but I am ok w/ not specifying it

<mjs> (note that IE doesn't even make it constructible via new XMLHttpRequest() so we can't 100% stick to just what they do in any case)

<iand> IE Mime type handling via URL Moniker: http://msdn.microsoft.com/workshop/networking/moniker/overview/mime_handling.asp

RB: we need an action for when .responseXML is set

<mjs> responseXML is always available when the load is completed

<mjs> (and I think probably not before but I dunno)

JL: mozilla creates a weird XML doc for illformed docs

JS: the awesome parseerror document!

RB: would you be opposed to dropping that

<mjs> another question is whether XHR should even be an EventTarget

<mjs> I think in IE it isn't

JS: No, as long as we provide a way for authors to detect parse errors
... if we make it an EventTarget we should define which events the UA fires on it

RB: might be better to keep for version 2

<mjs> in moz it is an EventTarget

<mjs> since it is not a Node there is no reason to fire events other than readystatechange and maybe load

<mjs> would allow more than one listener

<mjs> would be detectable from script per JL's rule

<mjs> could be a MAY

and error

RB: we should have a version 1 that just documents 'if you use these features it'll work in UAs'

GE: the way that new browsers do it is that they make the XHR an EventTarget

JS: it's the same as with onload. Probably better to keep it for version 2

<iand> IE Mime Type detection: http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

JS: we have to make sure we that we define the onreadystatechange property in such a way that it can be an EventListener in version 2

<darobin> ACTION: Jim to tell the WG what "this" is in the onreadystatechange callback, in IE (and other browsers

<trackbot> Created ACTION-49 - Get Jim to tell the WG what \"this\" is in the onreadystatechange callback, in IE (and other browsers) [on Charles Mccathienevile - due 2006-03-01].

JS: arguments to readystatechange is an issue since in version 2 it will have to be an Event object

<iand> http://www.webreference.com/programming/javascript/domwrapper/4.html

<anne> (Basically it is the one from the WHATWG with some changes. Needs much more changes...)

<dino> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/ab1b76cf-7dd9-46b5-b782-cc04823df117.asp

RB: can't be an Event object now since we don't have an EventTarget

JS: so how do we write the language such that we don't provide an argument now, but we do in version 2

AK: Are we only defining XHR for Ecmascript?

JS: since the property is a function, which i'm not sure if it's even possible in Java

<mjs> to make sense for other languages the event handler attrs have to be EventListeners (or better yet it needs to be an EventTarget)

<chaals> AK: Should we note that the name doesn't restrict the scope?

<chaals> RB: Yes

<mjs> the properties are actually EventListeners in moz and safari and converted to/from functions by the JS bindings

DJ: the charter says that it's ok for us to create ecmascript only specs

RB: Java has other APIs to do similar things anyway

<mjs> it is possible to define it in a reasonably language-neutral way, and add odd behavior only to ES bindings, same way that addEventListener can take a function in JS but not in other languages

<mjs> probably best to do that even if 1.0 is JS-only

<dino> that's the goal

mjs, the problem is that we want it to be different things in version 1 and version 2

mjs, in v1 it's just a function, in v2 it'll be an EventListener

<mjs> sicking, we can design such that the IDL is the same, but the JS binding quirks change in a compatible way

<mjs> (damn, forgot to use comma)

<chaals> (if you write name: the minutes magic will mark that as something that person said...)

<mjs> sicking, v1 of ES bindings can only allow setting function, v2 can allow setting function or object w/ handleEvent method as for other EventListeners (and can add EventTarget interface)

<mjs> sicking, but I think onreadystatechange might not be an event listener at all in moz, I think it doesn't get an event param under any circumstances

GE: which http methods should be supported

<dino> mjs, does Safari support GET, POST, PUT, DELETE, HEAD?

GE: GET, POST widly supported

<mjs> dino, I think it might only do a subset of those, but any it doesn't support would be considered bugs that we want to fix

JL: people use HEAD too

<dino> mjs, do you know what IE supports?

<dino> don't worry - found it

<mjs> dino, not off hand

<dino> 'The HTTP method - either "POST" or "GET"'

<JibberJim> IE maps everything through regardless dino.

<mjs> don't trust the docs

<bjoern> at the moment, the atom publishing protocol (blogging api) requires more than just get/post...

RB: there is a minimal number of methods that must be supported

<mjs> need to test all of these anyway


<mjs> how about PROPFIND?

<mjs> (for WebDAV use)

JS: so should we requires that any other be just forwarded?

<bjoern> SHOULD support any IETF standards track method, subject to implementation-defined security considerations...

JS: if all browsers support it why not just put it in the spec?

<iand> agree with bjoern

JL: it might not be interoperable in old browsers, like moz before 1.0

<darobin> ACTION: ID to build a test case to see what methods are supported in existing browsers

<trackbot> Created ACTION-50 - Build a test case to see what methods are supported in existing browsers [on Ian Davis - due 2006-03-01].

CN: it makes sense to let the various implementors test what they do in old versions of their UAs

<mjs> passing through other methods w/ headers and body should probably work but may not be interoperable

RB: next field is the uri argument

<mjs> safari may drop the body in current versions, that is a fixable bug though

<bjoern> (webdav has MOVE, COPY, LOCK, ...)

JL: i'm pretty sure IE will attempt to load any uri

<bjoern> javascript:?

ID: we should find out what is reliably supported across UAs

<bjoern> we might have to define what it means to POST to data:,... wouldn't make the spec lightweight...

<mjs> method should be ignored for non-http

<mjs> (and probably already is in existing UAs)

<dino> I suggest text saying "Implementers MUST support <some defined list>. The following is a list of methods supported in current browsers: <some other list>

<dino> or something like that

<JibberJim> It seems IE throws "invalid syntax error" if it doesn't recognise the scheme.

<darobin> WG: we agree with dino

<JibberJim> and permission denied for ftp

<darobin> RESOLUTION: for uri, we require http & https, for the rest you're on your own

<anne> See also : http://whatwg.org/specs/web-forms/current-work/#methodAndEnctypes

<iand> this is xml HTTP request after all

<bjoern> support for https:// is pretty meaningless if you don't say which SSL, TLS, ... versions...

RB: async is next

<mjs> restricting URI scheme would be contrary to AWWW

<bjoern> this is an API, not "linking"

JL: sync requests is a bad idea

<dino> I don't think we'd restrict. We'd just say which schemes are supported

<mjs> so it should be clearly stated as a minimum requirement

<dino> right

<chaals> JS: When we added interface for XSLT, getting two docs loaded and fed in was hard for people to figure out...

<mjs> ideally though it SHOULD be the same as the set of URI schemes supported by the UA in general, modulo security considerations

JS: sync loading is needed. Authors are struggeling bad to get async working

<chaals> [mjs, this makes sense - similar to what we plan to do with methods...]

RB: we should have text in the spec that strongly recommends using async
... authication

however that's spelled


RB: how should we handled failed login

<mjs> tricky to implement sync well (i.e. w/o blocking UI *and* without JS execution or timers happening between start of load and end)

<mjs> but not completely impossible

RB: it would be good to put the 403 page in the respons

mjs, yeah, everyone here has stories about previous horrible implementations :)

JS: what does IE do. We're trying to restrict ourself to that

<mjs> sicking, Safari still has a fairly horrible implementation

<mjs> IE has sync loading

<mjs> I dunno whether it is good

<gorm> mjs, what happens with Safari when authentication fails?

RB: IE gives the content of the 403

<darobin> ACTION: JS to check what Mozilla does when open() gets a 403 [recorded in http://www.w3.org/2006/02/22-webapi-minutes.html#action07]

<trackbot> Created ACTION-51 - Check what Mozilla does when open() gets a 403 [on Jonas Sicking - due 2006-03-01].

<mjs> gorm, I think it gives you a 403

<mjs> I have to go to bed

<mjs> good night all

<darobin> RESOLUTION: WG agrees that returning 403 and the content of the page is better than alternatives (prompting for password, throwing exception)

<mjs> will read scrollback later

<mjs_sleep> oh, we do prompt for password

<darobin> g'night!

<mjs_sleep> I thought you guys meant if the password fails

<mjs_sleep> (can be changed though)

<anne> g'night mjs!

JL: mozilla seems to just swallow the request in case of 403

JS: we don't even fire onerror?

JL: no you don't :)

<JibberJim> that was based on FF 1.5

GE: opera pops up the login dialog

DJ: it would be good to have some way where the script never sees the password

GE: that's in effect what opera does

JL: you could open an iframe where the user logs in and then that credential will be reused

RB: should we define that the credentials will be reused

JS: seems like a big thing to leave out

<dino> ACTION: Charles to weigh the pros and cons of having open() use the same auth params as the session

<trackbot> Created ACTION-52 - Weigh the pros and cons of having open() use the same auth params as the sessions [on Charles Mccathienevile - due 2006-03-01].

GE: IE only suppors basic auth
... opera supports most auth methods

JS: i think moz does too

<dino> ScribeNick: dino

XHR continued

RB: Caching - how should it work?

JL: I've shipped products that rely on the Modified-Since headers.

JS: Ah, so you want to set the header and then have the browser use the cache if possible.

JL: I don't really care if the browser cache knows it hasn't been modified.
... I don't want the browser to rewrite a 304 to a 200

RB: He wants the script to know that it hasn't been modified.

JS: So the browser should fake that if it has used its cache.

JL: A 200 is ok in that case.

JS: What is it that you are trying to avoid?

RB: Downloading a large resource that takes a while to process. Maybe you are polling every 10 secs - you want to get 304s to avoid processing.
... If you've set your If Modified Since header then he wants the right result.

GE: So if the browser returns from its cache, should it send a 304?

RB: So using the browser cache without Modified headers should return 200.
... The user makes a request without Modified headers. The result should be a 200, whether or not the browser cache was used.

JL: You want the behaviour of an HTTP caching proxy.

JS: You also want a way to force the browser cache to not be used.

GE: Use CacheControl.

RB: I like the idea of it being specified as an HTTP caching proxy, but we need to check if that is ok. Who wants to read chapter 13 of the HTTP spec?
... Does it have side-effects on other parts of the browser?

<scribe> ACTION: GE to review HTTP caching proxy side effects, chapter 13, to see if browsers can act as proxies

<trackbot> Created ACTION-53 - Review HTTP caching proxy side effects, chapter 13, to see if browsers can act as proxies [on Gorm Haug Eriksen - due 2006-03-01].

GE: What about redirects? They are a little related.

<darobin> RESOLUTION: having the browser behave as a caching proxy is a good idea, pending on Gorm's action-53

JS: How does it relate?

GE: What should you return? Should you follow it?

JS: I think we should follow it.

DJ: You have the Location header.

JS: But you don't want a redirect to another server. It is something that users should be aware of.

RB: We need to look at the 300's.

<darobin> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

RB: 301, 302, perhaps 303 are turned into 200. 304 is not.
... Not sure what to do with 300. The spec says it may happen automatically. We can't expose the list of choices.

JS: I'm not really comfortable requiring implementations to select one. Their HTTP library might not do it.

RB: I'm happy for them to select any one.

JS: Do browsers do anything with it? In Mozilla, you'll see the 300 response in the browser.

Jim writes some code to test it.

JS: Are the 300 response choices always machine readable?

<darobin> "If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection."

<iand> see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1

CMN: I'll open an ISSUE on this.

AvK: I think the spec is clear.

RB: When I say "turn into a 200" I mean "result in a stable response, maybe 200, 404 etc"

JS: We should specify that the baseURI property on the parsed document is based on the Location from which the content was retrieved.

ID: Do we need a way to look at the chain of redirects?

RB: I don't think so.

301 -> stable

302 -> stable

303 -> stable

304 see above, depend on If Modified Since headers

JS: We allow cross domain scripting in some cases.
... For system level code.

AvK: What should we do when you get a 305?

RB: What about saying that the browser should use the proxy?

305 -> stable, via the browser using the proxy.

306 unused

307 -> stable

ID: What about the 100s?

100 ignored, browser should handle it

101 ignored, browser waits for the actual response

SS: Should we have test cases for these responses?

Group: yes

RB: Most 200s will be passed through.

<JibberJim> sending a 100 in xmlhttp to IE locks up the browser...

JS: for 206, our chacing code probably caches partial downloads.

<JibberJim> and then it timesout with a 12031 status

ID: If I issue a GET and Mozilla adds a range header, I only expect to see a 200.

JS: Right.

<anne> http://www.ietf.org/rfc/rfc3229.txt

<iand> i.e. not a 206 because I didn't add the Range header

AvK: That RFC specifies something similar to 206

<sicking> I hope that is what we do. We should

AvK: Used in Atom. "I've read your feed until this particular point. Do you have anything new?"
... Do we want to address these codes in other RFCs?

RB: No, too much work.

JS: I don't want to forbid people from implementing these other specs.

RB: Are we agreed on all the 200s?

Group: Yes.

RB: So you won't get a 206 unless you ask for a Range.

<iand> range header usage isn't in latest Atom draft ( http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-07.html )

JL: Codes you don't know about? Should they be passed through.

RB: We should remain silent.

<iand> see http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html for discussion of usinf RFC3229 with feeds

XHR Cookeies

RB: How should they work? You get the ones for the uri?

JS: I think we should.

ID: That's not what a proxy would do.

RB: Maybe we only want to be a proxy in some cases.
... I think it makes most sense to pass the cookies along.

<bjoern> what cookies you send is a matter of request constructions, not a matter of beeing a proxy or not

JS: What about if I set the cookie header myself?

RB: Multiple cookie headers I think.

<iand> bjoern, we're suggesting the browser acts as a proxy for some parts of the requests but adds additional info from the current user context in others

all this talk of cookies is making me hungry


<anne> I guess it's http://www.ietf.org/rfc/rfc2965.txt

ID: I've seen a use case where people get a 202 No Content, but give you content in the cookie header. It stops the browser page from being changed.

<chaals> or http://www.faqs.org/rfcs/rfc2965.html

RB: Can we have multiple Cookie headers?

<bjoern> (yes, I'm just saying the model would be [script & ua generated request] -> [ua acting as proxy] -> [wire], so there is no contradiction)

AvK: We can have multiple SetCookie headers.

RB: Only one cookie header but it can contain multiple cookies. See Page 12.

<iand> see http://www.ashleyit.com/rs/rslite/ for a demo of using cookies to transmit data to applications

JS: That sounds like what we want to do, but I'm not sure we do it.

<chaals> ( for those who want cookie not cookie2, http://www.faqs.org/rfcs/rfc2109.html ...)

<iand> the technique is also discussed in Modern Web Design Using JavaScript & DOM book I think

UAs should set <code>Cookie</code> and <code>Cookie2</code> headers

appropriately for the given URI and given the user's current cookies,

and must allow authors to append values to these headers.

JS: Here are the headers that we forbid setting: Host, Content-Length, Transfer-Encoding, Via, Upgrade

AvK: WHATWG spec also disallows Accept-Charset, Accept-Encoding...

JS: It will be the browser that reencodes it for you.

JL: You may want a particular charset from the server.
... The browser will still handle it.

ID: If your Javascript just wants to deal with ASCII, you may want to make sure the encoding used is ASCII.

JS: You're probably right. Users can shoot themselves in the foot, but that's their problem.

RB: Right, if you ask for bzip2 encoding and you're not on Konquerer then too bad.

JS: If we weren't specifying what exists, I'd like to stop users shooting themselves.

RB: No, then your language is too restricted.

<scribe> ACTION: Jonas to ask Hixie why he's restricted some XHR headers

<trackbot> Created ACTION-54 - Ask Hixie why he\'s restricted some XHR headers [on Jonas Sicking - due 2006-03-01].

RB: You shouldn't be allowed to set Keep-Alive.

CMN: I'm generally unhappy with security restrictions being built into the spec.

JS: Yes.

CMN: We should have a note saying that browsers may restrict the headers.

RB: For example, it stops you from changing User-Agent.

JL: IE allows you to change the User-Agent.

JS: From looking at the Mozilla code, it looks like we allow it also. It may be overridden later.

CMN: We should have a security section.

AvK: Is that enough?

RB: We can give more details.

AvK: Why is that a seperate section?

CMN: Because this spec should not restrict the browser.

JS: I think it would be good to have a list for implementers.

CMN: Yes, we should say the list of typical security restrictions.

JS: About the User-Agent, maybe you want to stop modification because it would annoy tracking sites.

CMN: But browsers already allow this.

AvK: So we drop all the header restrictions?
... I've done it now.
... The spec says which headers can't be set. Should we say which headers can be set?
... we'll need to say which are appended, which are replaced, etc.

GE: Maybe say always replace?

RB: Kills your cookies.

JL: My testing indicates that setting cookies is ignored.

<gorm> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q234486

<JibberJim> so no..

<anne> (setRequestHeader())

<darobin> ACTION: RB to rewrite header setting section, making proposal derived on the "always replace" approach

<trackbot> Created ACTION-55 - Rewrite header setting section, making proposal derived on the \"always replace\" approach [on Robin Berjon - due 2006-03-01].

<scribe> ACTION: Jonas to draft a security section for XHR

<trackbot> Created ACTION-56 - Draft a security section for XHR [on Jonas Sicking - due 2006-03-01].

<anne> Security: http://www.ietf.org/rfc/rfc3552.txt

<bjoern> also http://www.ietf.org/rfc/rfc2828.txt

Errors in XHR

RB: Errors such as timeouts, endless redirect loops, no network....

AvK: What about non-wfed XML?

RB: Let's look at network-like ones first.

<JibberJim> http://support.microsoft.com/default.aspx?scid=kb;EN-US;193625

RB: What does IE, Mozilla, Safari etc do with errors now, such as timeouts?

GE: We don't do enough now.

RB: A timeout just fails eventually?
... IE throws an error for Permission Denied.
... I think we should throw more error codes.

<iand> ERROR_HTTP_HEADER_ALREADY_EXISTS and ERROR_HTTP_INVALID_HEADER might inform the work on setHeader

JL: IE throws exceptions that are only catchable using window.onerror.

RB: The problem here is that IE doesn't something unhelpful, and there isn't anything interoperable.
... ANything we do will be new.

JS: Do people write platform specific code?

AvK: What are the options?

Error Event

Throw Exception catchable on the global object - not acceptable

Status Codes - also not acceptable

JS: People probably check for 200 and everything else is an error.

RB: Another option is to have another readyState.

ID: That's forward compatible with a future solution that uses events.

RB: It isn't pretty but there doesn't seem to be a pretty solution.

Proposal - use readyState = 5 for error

JL: That will break some existing code. People might be waiting for readyState = 4

RB: Let's log this as an error and come back to it later.

<chaals> [Status codes identifying errors was not acceptable. "did I get a status I don't understand?" was another suggestion]

JS: I wonder if we should should set status to -1 and use statusText to describe the error.

<darobin> ACTION: DJ to raise an issue on XHR error - due tomorrow

<trackbot> Created ACTION-57 - raise an issue on XHR error [on Dean Jackson - due 2006-02-23].

<iand> some ready state analysis: http://www.quirksmode.org/blog/archives/2005/09/xmlhttp_notes_r_2.html

-- break --

<iand> scribenick iand

<anne> scribe: iand

<anne> scribenick: iand

<scribe> scribenick: iand

RB: we'll resume discussion of XHR now
... DOM3 Events tomorrow
... any issues related to send?

GE: yes

AVK: yes
... mozilla arguments

<anne> here are three _very_ simple ones: http://xmlhttprequest.testsuite.org/send/

<anne> (testcases)

JS: if we do allow it then it won't change FF 1.5

AVK: in whatwg draft send gets an object

RB: 2 versions, string or document
... any other issues?

GE: type of data sent is an issue. some browsers allows elements or document fragments to be sent

JL: IE just takes the .xml of the element

JS: IE doesn't support document fragments, they're all documents

RB: multiple roots?

JS: maybe

RB: should we list what is allowed?

JS: moz only supports string and document

ID: what about binary content?

RB: how do you represent? array of numbers?

JS: any browsers that don't support document and string?

JL: pretty sure all do, but haven't tested all

RESOLUTION: we should specify only DOMString and Document

JS: Mozilla throws if array passed in

JL: should just call toString on unknown objects
... object throws in IE so does array

RB: specify using host language's stringify mechanisms, not language dependent

JS: can't support zero-argument version of send in FF 1.5

<darobin> ACTION: JS to discuss the issue of zero-arg send with Mozilla, and report back

<trackbot> Created ACTION-58 - Discuss the issue of zero-arg send with Mozilla, and report back [on Jonas Sicking - due 2006-03-01].

RB: anything else on send


RB: any comments on abort?
... does it reset everything?

<Christophe> which is the state after abort ?

JS: in Mozilla, abort sets readyState to 4 then 0
... and readystatechange is called for each

ID: what does Opera do?

<Christophe> and how people (listening to readystatechange) knows the request have been aborted, is the HTTP status set to something special ?

GE: goes straight to 0, no other changes

JL: IE appears to go straight to 4
... goes to 0 but no readystatechange event

JS: actually Mozilla goes to 4, fires onreadystatechange, removes handler then goes to 0

JL: tests show Opera goes to 0 with no onreadystatechange event

<JibberJim> -

JL: Safari leaves it in state it was when abort was called
... going to 4 is probably a good thing, people probably relying on it

JS: do you clear event handler before or after going to 0?

JL: but should abort remove the handler anyway?
... IE seems to clear the handler too

RB: IE removes everything from object, i.e. it's like a new XHR object
... abort more like reset

JS: Mozilla only clears the handler

RB: so, do we reset or not?

JL: tests show Mozilla does clear everything

ID: should we specify in terms of behaviour, i.e. if you call abort you can't call send without setting fields again
... should we say object is left in undefined state and user should not call send again without specifying all parameters

JL: Opera appears to reset object

RB: we should say that abort sets state to 4, calls onreadychange, then resets object to clean

RESOLUTION: we should say that abort sets state to 4, calls onreadychange, then resets object to clean

RB: getResponseHeader - what should happen when there are multiple headers with same name?

AVK: current spec says that headers should be concatenated with a space
... header names must be compared case-insensitive

RB: someone needs to take an action to check the HTTP spec on concatenation

<scribe> ACTION: DJ to check HTTP spec to see whether concatenating values of headers with same names is acceptable in all cases [recorded in http://www.w3.org/2006/02/22-webapi-minutes.html#action18]

<trackbot> Created ACTION-59 - Check HTTP spec to see whether concatenating values of headers with same names is acceptable in all cases [on Dean Jackson - due 2006-03-01].

<bjoern> it's not, only if you can join the values with "," as defined in the spec for the header

<bjoern> Cookie is a bit special due to implementation issues, iirc...

JL: For getResponseHeaders IE returns you the first header, as does Opera 8.5, Mozilla concatenates with a comma

<bjoern> Multiple message-header fields with the same field-name MAY be

<bjoern> present in a message if and only if the entire field-value for that

<bjoern> header field is defined as a comma-separated list [i.e., #(values)].

<bjoern> (4.2)

RB: Safari returns undefined
... concatenation is best option

JL: should be like Mozilla behaviour

RB: agree

AVK: current spec says concatenation should be with comma followed by space

RESOLUTION: leave text as is

RB: move on to responseText
... if no encoding then go to Latin-1
... because it is default for HTTP

AVK: if no encoding specified but has UTF8 BOM, then should it be read as Latin-1?


RB: yes because they're valid Latin-1 characters so you can't tell difference

GE: according to WHATWG spec, responseText should be available while content is downloaded

RB: i.e. in state 3

AVK: draft does say that, but not sure about browser support

JS: Mozilla does do this

GE: but what about difference between headers and body?

<bjoern> yes?

<bjoern> (Latin1 per RFC 2616, if that was the question)

<dino> bjoern, uri for API being monkey in Icelandic

<gorm> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-September/004789.html

JS: if you get state 3 then you have all the headers

RB: should not enter state 3 until all headers received

<bjoern> http://is.wiktionary.org/wiki/api ?

AVK: getResponseHeader should be redefined to be available in state 3?

RB: should be totally available in 3 and 4

JS: Mozilla fires onreadystatechange multiple times for state 3
... number of times is dependent on low level network API, more or less every packet of data

AVK: Safari does this too

RB: should be called at least once?

JL: no, might be coming from cache

JS: should fire onreadystatechange for synchronous operations?
... IE does fires onreadystatechange multiple times for state 3 too

RB: Safari fires it once at end

JL: IE doesn't make responseText available on 3
... 3 indicates that headers are available

RB: no current interoperable behaviour
... spec should say that responseXml can only be guaranteed to be present in state 4
... must be null before then

AVK: current spec says that too

JS: is null in Mozilla

JL: IE may throw an exception

RESOLUTION: onreadystatechange MAY be called multiple times for state 3

JL: for responseXml, Mozilla is null in state 3, IE it is an empty string, Opera is a Document, Safari is undefined

ID: what about pipelined requests?

RB: what happens when you call send twice in a row?

AVK: draft says should raise error in any state other than 1

RESOLUTION: responseXml MUST be null in any state other than 4

DJ: but that isn't interoperable

RB: moving onto status
... why does it raise an exception?

JL: IE throws an unspecified error

JS: Mozilla doesn't throw on 1 or 2

ID: what does Mozilla return on readyState 1?

JL: it's available from 2 onwards

<darobin> RB: Safari never throws, it's available starting at 2

JS: headers are made available at 2

JL: Mozilla throws NSErrorNotAvailable at 1

RESOLUTION: status MUST be available in readyState 3 or 4 and raises an exception if not available

JS: what is purpose of state 2?

AVK: called as soon as send is sent

CMN: should we remove 2?
... should specify interoperable things

RB: it's used by everything except Opera

ID: could it be used to detect if DNS resolution has succeeded?

JL: probably goes straight to 4

AVK: IE6 resets onreadystatechange to null after open method is called if readyState is 4

RB: so open does a reset if it's in state 4

RESOLUTION: calling open when readyState is 4 resets the object

RB: do we keep readyState 2?

JL: can't see it being used by Opera in testing
... should say that 4 is only one you can rely on

RESOLUTION: keep all existing readyStates, authors should rely on checking for 4 only

JS: still issue of what to do about synchronous loading

RB: remaining issues...

AVK: how to resolve the URI argument of open if it is relative

JS: what to resolve the URI against?

AVK: DNS errors - what to do?
... responseXml has an attribute in IE for parse errors

JL: no interop there

AVK: no more issues

RB: end of session

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006-03-09$