RESOLUTION: we keep the log members only, then chair will send minutes to the public list after editing potential private stuff
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).
RESOLUTION: CMN elected co-chair for Web APIs WG
coffee break
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...)
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
RB: GET, POST, HEAD, PUT, DELETE
<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
authentication
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
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
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
ID
<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
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
none
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> - http://10.0.2.12/2006/2/300test.html
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?
Bjoern?
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
[End of minutes]