Re: XHR LC comments
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] Comments on the latest public working draft
On Tue, 13 May 2008 09:25:42 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: - On the send algorithm, step 4 (If stored method is GET act as if the data argument is null), why only GET and not HEAD, also? In order to subset HTTP as little as possible. Well, *if* you subset it, please make it in a consistent way. If the subsetting applies to GET, it should also apply to HEAD. Would it stop with HEAD or would there be more methods to consider going forward? If it's just HEAD I suppose we could add it, yes. It would stop with HEAD, because HEAD and GET by definition should do the same thing (except for HEAD not returning the response body). Actually, it seems that implementations do pass it through for HEAD. It is just GET where they don't and given that we can't allow it for cross-site GET requests anyway I think forward consistency is desirable. More background information is available in this thread: http://lists.w3.org/Archives/Public/public-webapi/2007Dec/thread.html#msg8 -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: TLS error handling in XMLHttpRequest
On Tue, 13 May 2008 16:49:03 +0200, Thomas Roessler [EMAIL PROTECTED] wrote: the Web Security Context Working Group is, as you might know, working on user interactions for Web user agents when they encounter TLS error conditions. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors We notice that the XMLHttpRequest Last Call Working Draft specifies that XMLHttpRequest can be used over both HTTP and HTTPS, but does not specify behavior if TLS negotiation fails for an HTTPS URI. This would only be the case during a man in the middle attack or in case the server randomly generates certificates, but I suppose it deserves a mention nonetheless :-) We can see several reasonable choices for this case: - XMLHttpRequest specifies that this case is treated as a generic network failure, and handled by the invoking script. No user interaction occurs, and certificate validity errors are treated as hard herror conditions. I've specified this by mentioning TLS negotiation failure under In case of network errors as per our brief F2F discussion on this matter: http://dev.w3.org/2006/webapi/XMLHttpRequest/ (ACTION-444 in Web Security Context.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[XHR] referencing HTML5
There have been a lot of messages about referencing HTML5 and how we can mitigate that. I don't think that copying the text from HTML5 is an option. The Window specification is fairly complex and especially the interaction with browsing contexts is a complex bit of HTML5 that I don't feel confident taking over. The same goes for defining the origin policy. If someone were to volunteer to define these outside of HTML5 we could refer to that specification but so far that has not happened. So we have two reasonable options I think: 1) Keep the references intact. 2) Make various things implementation defined and hint with non-normative notes that this will be defined by HTML5 in the future. Option two would be feasible but implementors have actually requested that we define in detail how URIs are resolved and what exactly the same-origin policy implies for XMLHttpRequest. I don't think it's worth dropping all that work on the floor. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] Comments on the latest public working draft
Anne van Kesteren wrote: On Tue, 13 May 2008 09:25:42 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: - On the send algorithm, step 4 (If stored method is GET act as if the data argument is null), why only GET and not HEAD, also? In order to subset HTTP as little as possible. Well, *if* you subset it, please make it in a consistent way. If the subsetting applies to GET, it should also apply to HEAD. Would it stop with HEAD or would there be more methods to consider going forward? If it's just HEAD I suppose we could add it, yes. It would stop with HEAD, because HEAD and GET by definition should do the same thing (except for HEAD not returning the response body). Actually, it seems that implementations do pass it through for HEAD. It is just GET where they don't and given that we can't allow it for cross-site GET requests anyway I think forward consistency is desirable. More background information is available in this thread: http://lists.w3.org/Archives/Public/public-webapi/2007Dec/thread.html#msg8 Yep, lots of discussion. Anyway, an implementation that drops the body on GET but not on HEAD *very* clearly is buggy. The XHR spec should not mandate these kind of bugs. BR, Julian
Re: [XHR] referencing HTML5
Anne van Kesteren wrote: There have been a lot of messages about referencing HTML5 and how we can mitigate that. I don't think that copying the text from HTML5 is an option. The Window specification is fairly complex and especially the interaction with browsing contexts is a complex bit of HTML5 that I don't feel confident taking over. The same goes for defining the origin policy. If someone were to volunteer to define these outside of HTML5 we could refer to that specification but so far that has not happened. So we have two reasonable options I think: 1) Keep the references intact. 2) Make various things implementation defined and hint with non-normative notes that this will be defined by HTML5 in the future. Option two would be feasible but implementors have actually requested that we define in detail how URIs are resolved and what exactly the same-origin policy implies for XMLHttpRequest. I don't think it's worth dropping all that work on the floor. If you decide to keep the references, I don't see how this document can advance. Not sure how it works in W3C land, but in IETF land you simply can't have a normative reference to something that is work in progress. BR, Julian
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Julian Reschke schreef: Anne van Kesteren wrote: On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst [EMAIL PROTECTED] wrote: Why was this changed? Why should user agents pretend that they know what kind of resource the user expects by setting an Accept header that is unreliable? FWIW, Internet Explorer and Safari set the (reasonably acceptable */*), but it would be better to leave it out entirely. Also see: http://www.grauw.nl/blog/entry/470 It was pointed out by another Last Call comment that not setting the Accept header causes servers to break. Given the results above I suppose we could require that for XMLHttpRequest purposes it is at least always set to */*. Would that work? Not setting the Accept header means the same thing as setting it to */* (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1.p.8), so these servers simply are buggy. I think it's better not to add more workarounds, but to let the XHR clients deal with these broken servers, by explicitly setting the header. That would also be a possibility, however assuming that no current server exhibits this broken behaviour, there should then probably be a list of Server header identifiers which can be used to identify when to send Accept: */* and when to send nothing at all (assuming that the broken server(s) all identify themselves). ~Grauw -- Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~ Laurens Holst, student, university of Utrecht, the Netherlands. Website: www.grauw.nl. Backbase employee; www.backbase.com. begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: XHR LC comment: Accept header went from MUST NOT to SHOULD
Anne van Kesteren wrote: On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst [EMAIL PROTECTED] wrote: Why was this changed? Why should user agents pretend that they know what kind of resource the user expects by setting an Accept header that is unreliable? FWIW, Internet Explorer and Safari set the (reasonably acceptable */*), but it would be better to leave it out entirely. Also see: http://www.grauw.nl/blog/entry/470 It was pointed out by another Last Call comment that not setting the Accept header causes servers to break. Given the results above I suppose we could require that for XMLHttpRequest purposes it is at least always set to */*. Would that work? Not setting the Accept header means the same thing as setting it to */* (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1.p.8), so these servers simply are buggy. I think it's better not to add more workarounds, but to let the XHR clients deal with these broken servers, by explicitly setting the header. BR, Julian
Re: TLS error handling in XMLHttpRequest
On 2008-05-16 10:56:50 +0200, Anne van Kesteren wrote: We notice that the XMLHttpRequest Last Call Working Draft specifies that XMLHttpRequest can be used over both HTTP and HTTPS, but does not specify behavior if TLS negotiation fails for an HTTPS URI. This would only be the case during a man in the middle attack or in case the server randomly generates certificates, but I suppose it deserves a mention nonetheless :-) A server randomly generating certificates would be a neat test case for a bunch of these things. Man in the middle attacks or, for that matter, badly done captive portals, are the more likely scenarios, though. We can see several reasonable choices for this case: - XMLHttpRequest specifies that this case is treated as a generic network failure, and handled by the invoking script. No user interaction occurs, and certificate validity errors are treated as hard herror conditions. I've specified this by mentioning TLS negotiation failure under In case of network errors as per our brief F2F discussion on this matter: http://dev.w3.org/2006/webapi/XMLHttpRequest/ (ACTION-444 in Web Security Context.) I would suggest to explicitly say that a failure of the server identity check (section 3.1 of RFC 2818) MUST cause the client to terminate the connection. (RFC 2818 gives a choice of either giving the user a choice or terminating the connection.) -- Thomas Roessler, W3C [EMAIL PROTECTED]
Google JS lib key codes list
Came across this: http://doctype.googlecode.com/svn/trunk/goog/events/keycodes.js Interesting stuff in our quest to standardise legacy key events and the keyCode property. -- Hallvord R. M. Steen Core QA JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: XHR LC comments
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
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 vs setting request headers
Julian Reschke wrote: Yes, I noticed that. For instance, it happens for application/..+xml, where it's really useless. Shouldn't this be restricted to text/*? That could perhaps be done. The initial implementation just does it no matter the MIME type so as to avoid making assumptions about particular types (always a good thing). -Boris
Re: XHR vs setting request headers
Boris Zbarsky wrote: Julian Reschke wrote: Yes, I noticed that. For instance, it happens for application/..+xml, where it's really useless. Shouldn't this be restricted to text/*? That could perhaps be done. The initial implementation just does it no matter the MIME type so as to avoid making assumptions about particular types (always a good thing). This assumes that every non-text/* mime type *can* take a charset parameter, which IMHO is not true. But this probably only becomes relevant once we have non XML/string based ways to set the body. BR, Julian
Re: XHR vs setting request headers
Julian Reschke wrote: This assumes that every non-text/* mime type *can* take a charset parameter, which IMHO is not true. But this probably only becomes relevant once we have non XML/string based ways to set the body. For what it's worth, Mozilla does have such a way (only available to privileged code). When the body is set from a byte stream directly, we don't touch the charset arg. -Boris
