Re: cookies and XMLHttpRequest
On Mon, 15 May 2006 23:54:07 -, David Flanagan [EMAIL PROTECTED] wrote: Perhaps you did not see my response to Jonas' message: Yeah, sorry about that. [...] My original point was simply that there is a non-parallelism in the spec as it stands now. Outgoing cookies are explicitly addressed, but incoming cookies are not. If you make it clear that XMLHttpRequest uses the HTTP facilities of the UA, then that would satisfy me. The specification has the following regarding this: If the user agent supports HTTP State Mangement [RFC2109][RFC2965] it should persist, discard and send cookies (as received in the Set-Cookie and Set-Cookie2 response headers, and sent in the Cookie header) as applicable. ... and the specification has HTTP in its name. I think it's clear enough and the WG agrees, fwiw. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: cookies and XMLHttpRequest
I *think* this was covered in the omnibus proposal for send setRequestHeader that I made a while back... On 2006/05/16, at 12:54 AM, David Flanagan wrote: Anne, Perhaps you did not see my response to Jonas' message: So then you just need to add something to the spec that makes it perfectly clear that XMLHttpRequest scripts the HTTP subsystem of the UA, and does not create its own network connections and implement rudimentary HTTP itself... Perhaps you could add a note of this sort to the spec for getAllRequestHeaders() something saying that the UA sees these and processes them as it would for an HTTP request initiated by the end user. My original point was simply that there is a non-parallelism in the spec as it stands now. Outgoing cookies are explicitly addressed, but incoming cookies are not. If you make it clear that XMLHttpRequest uses the HTTP facilities of the UA, then that would satisfy me. Anne van Kesteren wrote: On Mon, 24 Apr 2006 07:15:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: What I meant, however, was that you need to specify that the browser must/should/should not store cookies sent with the response to an XMLHttpRequest. I'm not sure that we actually need to specify this. A UA supporting cookies should use them in any and all http transfers. If we go and specify how every possible web feature interact with XHR we're never going to get done. I tend to agree. David, what do you think? -- Mark Nottingham [EMAIL PROTECTED]
Re: cookies and XMLHttpRequest
Anne, Perhaps you did not see my response to Jonas' message: So then you just need to add something to the spec that makes it perfectly clear that XMLHttpRequest scripts the HTTP subsystem of the UA, and does not create its own network connections and implement rudimentary HTTP itself... Perhaps you could add a note of this sort to the spec for getAllRequestHeaders() something saying that the UA sees these and processes them as it would for an HTTP request initiated by the end user. My original point was simply that there is a non-parallelism in the spec as it stands now. Outgoing cookies are explicitly addressed, but incoming cookies are not. If you make it clear that XMLHttpRequest uses the HTTP facilities of the UA, then that would satisfy me. Anne van Kesteren wrote: On Mon, 24 Apr 2006 07:15:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: What I meant, however, was that you need to specify that the browser must/should/should not store cookies sent with the response to an XMLHttpRequest. I'm not sure that we actually need to specify this. A UA supporting cookies should use them in any and all http transfers. If we go and specify how every possible web feature interact with XHR we're never going to get done. I tend to agree. David, what do you think?
Re: cookies and XMLHttpRequest
David Flanagan wrote: Your XMLHttpRequest draft of 05 April 2006 specifies that XMLHttpRequest should automatically include cookies in outgoing requests. But it does not specify what should be done with cookies included in incoming responses. What does current implementations do? Are the cookies available through .responseXML.cookies? Note that the document would probably have to be an XHTML document for that to work (which means that it won't work in IE since it doesn't support XHTML). / Jonas
