SV_MEETING_TITLE -- 03 Jul 2008

<chaals> ScribeNick: mjs

sicking: I propose that we accept the suggestion that when you opt into cookies, you can't allow wildcard

weinig: what is the threat model?

<chaals> MJS: I think we should only allow *, or specific hostname - for private stuff there is no value in having wildcards, for public data there is no need no to have *

<chaals> AvK: So if it had wild card and asked for cookies it is a fail?

<chaals> ... Processsing instruction?

<chaals> MJS: I think we want to do that seperately. The use case is a static file, and it would be a burden to make a cgi wrapper.

thanks chaals

<chaals> ... in that case you are likely to be using public data, so you don't need an ACL

kriszyp: we're in favor of the PI being removed

<chaals> IH: I can live with it too

AVK: can support for the PI be added later?

JS: yes

<sicking> Proposed resolution: Remove the PI

<sicking> Proposed resolution: Make the opt-into-cookies (still to be drafted) syntax such that you can't opt in cookies while using a wildcard

<sunava> Removing PI sounds awesome

<sunava> So does the cookies being disabled with wildcard!

<sicking> Proposed resolution: Simplify the allow syntax to only allow a single origin, or whildcard. I.e. remove subdomain wildcarding, lists of origins, and the exclude syntax

MJS: I agree with all resolutions

AVK: me too

CMN: any objections?

IH: lgtm too

<arun> I agree with all resolutions

SW: I like it

DS: we should have a section that documents the name changes, for review purposes

AVK: feel free to make one

JS: redirect issue - we need a formal resolution

<sicking> Proposed Resolution: Check for AC opt-in on all steps in the redirect

RESOLUTION: remove the PI
... do not allow an access control wildcard together with opting into cookies
... Simplify the allow syntax to only allow a single origin, or whildcard. I.e. remove subdomain wildcarding, lists of origins, and the exclude syntax
... check access control opt-in on all steps of a redirect

JS: we had an informal discussion about IE compatibility
... yesterday, we had the double GET proposal, and the API flag proposal
... we focused on the double GET proposal
... pro for double GET: doesn't require API flag

MJS: pro for double GET: does not require coupling between client and server to pre-agree on cookies

JS: con for double GET: if GET has side effects (which it shouldn't) these may happen twice
... pro for API flag: allows preflightless POST
... pro for API flag: allows IE compat if IE is able to change XDR impl in IE8
... con for API flag: requires API flag in all specs that want to load private data cross site

ZB: we can use the expando solution

KZ: would it be problematic if the spec didn't specify what the default was?

JS: it wouldn't be a compatibility issue

CMN: it would be an author confusion issue

MJS: any solution like this has the API flag downside of preventing auto-negotiation

IH: what is the use case for POST without cookies

AVK: flash allows that

IH: flash has a lot of security bugs

JS: there is one thing we're changing - allowing arbitrary content types on POSTs

IH: we've got things backwards

JS: I now think it is ok to have POST w/o cookies

KZ: why allow this?

JS: flash has a header-based solution too

IH: the big problem I have with this is the migration path
... before a site gets the benefits it has to change
... clients would have to change to be able to use cookies

ZB: API flag is better

<chaalsXO> q/

AVK: you can cache the response for the first get

SW: when google does the current model you don't have cross-site requests

IH: you're saying we should always request cookies

JS: your use case is not important

(further discussion along the same lines)

<sunava> ...

MJS: we should not discuss the merits of the API flag, just whether MS is willing to adopt given this change

IH: if Microsoft is willing to commit, we will cede the point

<chaalsXO> MJS: The interesting thing here is whether we can a solution that IE can and will adopt

<off the record conversation?

SD: I like the proposal personally, I can't commit yet without talking to more senior folks first

ZB: the timeline is very short, we have to make the decision quickly

SD: we will give an answer by Monday or Tuesday

JS: when would you need the final spec proposal

SD: the question would be whether the spec will change again

sync and async calls

<chaalsXO> ZY: Don't allow sync is a request we get a lot.

ZY: suggestion, don't allow sync XHR for cross-site calls

SW: I don't think that is a good idea

<chaalsXO> KZ: We are built on sync...

<chaalsXO> MJS: Since we can't remove sync in the same-site case now, making it ipossible in new cases won't help...

<chaalsXO> ... so we are sadly stuck with the problem

SD: my deal with the async vs sync debate is that I think async is the right way moving forward

<arun> A listing of cross-site mechanisms: http://www.arunranga.com/articles/browser-cross-site.html

JS: should there be a UI to protect user's private data
... this discussion should probably be outside this working group

<chaalsXO> SD: Would like to have that discussion

<Zakim> chaalsXO, you wanted to float the silly 'shall we change the names' idea again

<sicking> it applies as much to iframes as it does to Access-Control

CMN: should we have an async-only API that is otherwise thesame as XHR, for cross-site?

JS: no matter what mechanism we use to remove synch cross-site, I see a cost in doing

CMN: the win is when people do cross-site they will do async

JS: we have two incompatible requirements

SD: I can make a suggestions

(off the record discussion)

<chaalsXO> [people have different customers, need to balance the needs they have with the need for standards]

SD: can we add flexibility to the spec?

AVK: leaving things undefined has historically led to really bad results

ZY: I don't know if anyone is going to implement a new XHR

(general disagreement)

MJS: ActiveX constructor vs. XMLHttpRequest constructor gives you a free versioning hook

<chaalsXO> MJS: IE has 2 ways to do an XHR - one is compatible. That gives a free versioning hook. I would guess that you can freeze the ActiveX one for people who rely on IE behaviour, and move the one compatible with the web to be compliant

<chaalsXO> 10 minute break

<MikeSmith> scribenick: MikeSmith

<scribe> scribe: MikeSmith

Test cases for XHR1

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/ -> Anne's tests

<chaalsXO> AvK:(And Hallvord's)

Present now: Hixie, anne, chaalsXO, shepazu, Sunava, Gideon, MikeSmith, mjs, weinig, Zhenbin

chaalsXO: Sunava, you guys have run these tests?

sunava: Yeah

[discussion about the fact that reviewing each test will take a lot of time]

<anne> ^^ Potential bugs identified in XHR LC Test Suite

<sunava> http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0034.html

[sunava reviews comments about tests that his team found problems with]

[discussion about a particular test that's actually in part testing DOM support]

sunava: also, 4.32

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/open/032.htm

<chaalsXO> ZX: We may not do this because of security

<chaalsXO> AvK: most browsers fail

<chaalsXO> ... and not sure this needs to be a real test.

Hixie: this looks like it is effectively a network timing test
... we shouldn't use a timeout at all for this kind of test ... we don't need the timeout at all

weinig: we should remove the timeout from this test
... otherwise it otherwise looks OK

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/abort/003.htm

<chaalsXO> [resolved to keep the open/032 with the timeout removed]

mjs: crazy to reset the event listeners

<anne> (mjs actually said that)

<mjs> ywH RHr qA MW

<chaalsXO> network problem - will return to this

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/onreadystatechange/004.htm

ljU EUe dN ZJ

<chaalsXO> ZX: We don't allow re-entrants...

weinig: just re-open, don't need to use new object, can just re-use the same object

anne: check if ready state is 4
... if so, process it, and start a new request using the same object
... it works ...
... in most browsers ...

weinig: you can open it and use a new URL

Zhenbin: do that and you just end up a stack the just keeps growing
... IE doesn't support this and we have never in 10 years had any customer request for this

anne: it works fine in other browsers

mjs: why should event dispatch for the XHR case be different from event dispatch for other things?
... Safari has always had it be re-entrant, and don't see any need to change for this

chaalsXO: I suggest we raise an issue for this and ask the FF guys for feedback also

<chaalsXO> ISSUE: Shoulld re-entrance be allowed foronreadystatechange?

<trackbot> Created ISSUE-33 - Shoulld re-entrance be allowed foronreadystatechange? ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/33/edit .

http://tc.labs.opera.com/apis/XMLHttpRequest/send/009.htm

<chaalsXO> and http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/017.htm

chaalsXO: sounds like what we are testing is not XHR-specific

Zhenbin: INVALID_STATE_ERROR bug is a bug in the DOM, not in XHR

Hixie: yeah, that's the bug this is exposing

Zhenbin: so the XHR spec is introducing dependencies on other specs?

chaalsXO: it's a failure in your DOM implementation, but if you can't pass it, then you can't conform to the XHR spec

<Hixie> thx

Hixie: XHR doesn't say "raise an exception", it says "raise this particular DOM exception"

anne: this exception is thrown in other places

<anne> (open() method, step 4)

chaalsXO: it is qualitatively a different kind of test

weinig: I don't think everybody agrees that's true, actually

chaalsXO: if we can mark out the other tests in this class, maybe we can make some progress on this

<chaalsXO> We set aside this test for now and move on.

sunava: spec could say, "must throw an exception, should throw [specific exception]"

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/send/011.htm

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

<chaalsXO> [definition in the spec]

<chaalsXO> SW: If you are expecting a string and pass an object it gets toStringed

weinig: basic JS behavior is if you pass an object to a method that expects a string, it gets converted the object to a string

<chaalsXO> ZX: We disabled it because we think there is a security issue

anne: stringification by calling toString() is defined in Javascript
... stringification by calling toString() is mandated by the ecmascript spec

Zhenbin: this is a security problem
... it could cause a crash ...

mjs: dynamic typing is not a violation of type safety
... there is nothing that XHR specifically doing in regard to toString()
... when current implementations do different things, than we have to choose something to spec anyway, and that means some implementation will break

sunava: I'm concerned we are going to run into this same problem with other parts of the spec
... I don't see a way forward ...

<chaalsXO> we don't have a way forward here

[reading through next test]

http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm

weinig: I don't think you're allowed to do parent.past

anne: could probably use postMessage()

weinig: yeah, that probably would be better ... it's interoperable
... are Javascript URIs allowed to access their parent frame?

chaalsXO: does anyone pass this test?

[discussion about what the correct failure should be here]

chaalsXO: what is this test testing?

anne: You'd have to ask Hallvord
... but basically it is more advanced iframe test
... but looking at it now, it is clear that the expected result should be to fail

Hixie: it's testing something useful, but it's testing it wrong

anne: I will change it, or I will ask Hallvord to change it

trackbot, status?

<trackbot> This channel is not configured

<chaalsXO> ACTION: Anne to change test http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm and propose it again [recorded in http://www.w3.org/2008/07/03-wam-minutes.html#action01]

<trackbot> Created ACTION-12 - Change test http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm and propose it again [on Anne van Kesteren - due 2008-07-10].

Hixie: all the tests with timeouts in them, the timeouts should be removed

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/001.htm and http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/004.php have test harness issues

<chaalsXO> RESOLUTION: We don't *want* tests to have timeouts

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/001.htm

<chaalsXO> (for previous pair, we need to deal with harness issues, but te

<chaalsXO> and timeouts, but tests are basically sound)

chaalsXO: send 5, 7, & 8

Ahmed (MS XHR developer) joins the meeting

<chaalsXO> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/034.php and http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/035.php

<weinig> http://dev.w3.org/2006/webapi/XMLHttpRequest/#setrequestheader

weinig: in the spec, number 3.. raising the exception will cause the test to never finish

anne: check if it's a valid HTTP header value, if it's not, throw

weinig: the test here is incorrect

sunava: so the spec is correct, but the test is wrong

[discussion about the fact that we all want to test suite to have thorough coverage and expose existing bugs so that we can fix them]

sunava: my concern is, in the CR phase, will we be able to say that the test suite is complete?
... that we are confident in the test suite ?

mjs: the point of CR is that we freeze the spec and then to *exit* from CR, then we need to have the test suite compelte

weinig: tests show only if some implementation is not conformant to the spec
... they can't show that a particular implementation *is* conformant

Hixie: when we get towards exiting from CR, then we should evaluate using it

<Zakim> chaalsXO, you wanted to say "and MS contributing more tests is therefore very welcome..."

Hixie: but the test suite will still grow after that, for years ...

chaalsXO: even tests where everybody passes are valuable

sunava: so we don't ever move forward from CR if we have known issues in the test suite?

[re-affirmation that we never move on from CR for any spec if there are unresolved problems in the test suite]

<Hixie> "bbl"

<sunava> s+

<chaalsXO> Thanks to MS for hosting and for last night's dinner, to Ann Bassetti and Opera for houseboat hanging out, and to everyone for a productive meeting with a lot of progress...

<chaalsXO> Meeting adjourned

chaalsXO: Big thanks to Microsoft for hosting the meeting, and for the great dinner at Maggiano's -- and thanks in particular to Sunava for all the work he's done to organize. Great meeting, we made a lot of progress.

- DRAFT -

SV_MEETING_TITLE

03 Jul 2008

Attendees

Contents

sync and async calls

Test cases for XHR1

Summary of Action Items

Scribe.perl diagnostic output