Re: XMLHttpRequest security section draft
On Mon, 20 Mar 2006 20:00:19 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: Here's a draft for a security section of the XHR spec. It's probably in desperate need of editing from someone with more spec writing experience then me, but it's a start. That start has now been integrated http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?content-type=text/html;%20charset=utf-8#security into the editor's version. It probably needs a lot of work... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: First Public WD of XMLHttpRequest released
On Thu, 06 Apr 2006 11:51:17 +0200, Jim Ley [EMAIL PROTECTED] wrote: I don't see why responseText MUST be null other than in readyState 3 or 4, why not undefined (e.g. if the firing of the 2 is delayed for some reason then data could be available) Equally MUST on 3 is incompatible with existing implementations. It's never null. If the firing of the 2 is delayed, isn't that just a bug? No, we're not mandating that events fire in realtime - we can't as ES is single threaded etc. Another way of saying is that until you fire the event the attribute MUST be the empty string... The MUST on 3 is incompatible with existing implementations in what way? MS's XHR implementation throws an error on 3. I'm in favor of leaving the specification as is and considering what IE does at the moment as a bug. alert( ) isn't defined anywhere, traditionally print has been used as a dummy function in ES code. Any pointers of its use? The ES spec, just changing alert to print... Used a print() function instead. by data.xmlEncoding, if specified and supported, or UTF-8 otherwise Makes some sense to me... I still don't see the point of the restriction at all, and inputEncoding would be a better option than xmlEncoding - if we're assuming the server knows the best format for a document serialisation, but I don't see the point of requiring such behaviour. See ISSUE-83. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ISSUE-29: how is uri parameter of the open() method resolved
On Tue, 28 Feb 2006 02:38:50 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: What we do is that we use window.document.baseURI, most likely for IE compat wrt interaction with base. It is worse if multiple documents are calling each other and there are XMLHttpRequest objects involved. Then it is more or less unpredictable in mozilla. During the F2F we resolved to go with what IE does now which is more predictable. I drafted something http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html?content-type=text/html;%20charset=utf-8#definitions but it should probably get some additional references and a bit more clarification. Suggestions are welcome. What we resolved for ISSUE-29 is that the XHR object has an intrinsic property holding Window.document.baseURI from the Window it was created in. That intrinsic property never changes, etc. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest Object feedback
On Fri, 21 Apr 2006 15:58:27 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: example) would contain a user name and password. I *assume* you're referring to the userinfo production in RFC3986; e.g., http://user:[EMAIL PROTECTED]/path/?query It may be better to use this terminology (userinfo) explicitly, along with an appropriate reference. Also, AIUI, the security gods have determined that userinfo is a no- no in URLs, and IE (for example) doesn't support it (at least in the browser, ... Internet Explorer removed support for illegal HTTP URLs such as the one you've provided above because it has been abused too much in phishing mails. For other schemes where this is perfectly valid, like ftp, it works just fine in Internet Explorer. What does IE does in such cases and do we want the draft to reflect that? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - no interoperable implementations
On Wed, 26 Apr 2006 07:10:51 +0200, Karl Dubost [EMAIL PROTECTED] wrote: The specification is here to set what is the correct behavior for the technology. Certainly there will be problems of interoperability, because of the history of the development. But I believe that a complete Test Suite should help to solve these issues by showing, don't tell what is the correct behavior. I would suggest to suppress most in the sentence and believe. The sentence contains also a prose which might be obsolete after a few years as it is only valid now. Perhaps we should move this to the history section, if we really need one (see other reply)? Yes it could be a solution And would satisfy your comment? We're planning on doing this for the next draft. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest.abort()
On Wed, 26 Apr 2006 16:22:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote: This has been asked a couple of times before. At some point reset will be defined and it will say that all members of the object are set to their initial value (as if you create a new instance of the object yes, I suppose)... Hopefully it will also include a requirement that any active connections are dropped, and so forth? Do we really want to define in that level of detail? Currently it says: When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. ... but perhaps it should only say the object is resetted and no new data should be made available to the object or something along those lines. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Extension HTTP methods
Anne van Kesteren [EMAIL PROTECTED] Currently some browsers have a whitelist and others have a blacklist and the group has resolved to go for a whitelist containing all safe methods that currently exist, unless the IETF comes up with good reasons not to. I disagree with this decision, I do not want any methods to be disallowed generally, if user agents choose to disable some specific ones for security reasons then that is fine (I'm happy for them to choose to disable POST for security reasons if they have security reasons even, security reasons trump anything) but to hobble the object to prevent using future HTTP based mechanisms is unhelpful, and not warranted. There are currently some methods that can't be allowed for security reasons and because such method smay be introduced in the future as well allowing arbitrary method names does not seem like a good idea. I think you need to list these methods that cannot be used for security reasons, to explain more of the motivations for this decision. It also appears to be a direct reversal of the decision at the previous f2f (issue 74) It would be good to see what had changed in between to motivate the change, as there was no public discussion, other than more support for having any verb. Cheers, Jim.
Re: XMLHttpRequest.abort()
On Sun, 14 May 2006, Anne van Kesteren wrote: On Wed, 26 Apr 2006 16:22:49 +0200, Ian Hickson [EMAIL PROTECTED] wrote: This has been asked a couple of times before. At some point reset will be defined and it will say that all members of the object are set to their initial value (as if you create a new instance of the object yes, I suppose)... Hopefully it will also include a requirement that any active connections are dropped, and so forth? Do we really want to define in that level of detail? Yes. Currently it says: When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. That's fine. It's important to specify this because it can end up being something the author relies on (e.g. a CGI script could fail in different ways depending on how the UA handles the connection, etc). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR constructor example
On Sun, 14 May 2006, Anne van Kesteren wrote: var request = new XMLHttpRequest(); Given that it doesn't have to be a request I think 'r' is saver or perhaps just 'x'... Please don't use single letter variable names for anything but loop index variables (in languages that require those), it's generally considerd quite bad practice. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
ACTION-148: responseText and encoding
reponseText now reads: If the codetermreadyState/term/code attribute has a value other than 3 (Receiving) or 4 (Loaded), it MUST be the empty string. Otherwise, it MUST be the fragment of the entity body received so far (when codereadyState/code is 3 (Receiving)) or the entity body when codereadyState/code is 4 (Loaded)), interpreted as a stream of characters. If the response includes a codeContent-Type/code understood by the UA, with the exception that the rule in the final paragraph of section 3.7.1 of [RFC2616], and the rules in section 4.1.2 of [RFC2046] MUST be treated as if they specified the default character encoding as being UTF-8. Invalid bytes MUST be converted to U+FFFD REPLACEMENT CHARACTER. If the UA can't derive a character stream in accord with the media type specification, codereponseText/code MUST be codenull/code. This seems a lot better than how http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#dfn-responsetext reads at the moment, but I've the feeling I should add some more references. Perhaps [RFC2616] after the first paragraph for entity body etc.? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Extension HTTP methods
On Sun, 14 May 2006 13:59:34 +0200, Jim Ley [EMAIL PROTECTED] wrote: There are currently some methods that can't be allowed for security reasons and because such method smay be introduced in the future as well allowing arbitrary method names does not seem like a good idea. I think you need to list these methods that cannot be used for security reasons, to explain more of the motivations for this decision. It also appears to be a direct reversal of the decision at the previous f2f (issue 74) It would be good to see what had changed in between to motivate the change, as there was no public discussion, other than more support for having any verb. I'm just stating the resolutions as they have been made here. Feedback from implementors suggested that TRACE and CONNECT have issues and that future HTTP methods might become problematic (new specification released, servers updated, UAs are not, hole). What was raised against that is that it hurts adoption of new HTTP methods. That's true for all other types of APIs as well though. Internet Explorer 7 as opposed to Internet Explorer 6 uses a whitelist and other browsers vendors are planning to do the same thing. The whitelist would contain all safe methods currently spreaded over various RFCs. Mark Nottingham would report back if the IETF was ok with this approach or not. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XMLHttpRequest.abort()
On Sun, 14 May 2006 14:00:08 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Currently it says: When invoked, this method MUST cancel any network activity for which the object is responsible and reset the object. That's fine. Ok! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-148: responseText and encoding
Anne van Kesteren [EMAIL PROTECTED] On Sun, 14 May 2006 14:25:01 +0200, Jim Ley [EMAIL PROTECTED] wrote: This is another difference that is not compatible with existing implementations, why is the 3 not a SHOULD? to meet the goals of being compatible with existing implementations. Which is a seperate issue I know, but it hasn't been resolved from when I raised it last time... You got a reply http://www.w3.org/mid/[EMAIL PROTECTED] on that one. Please keep that issue out of this thread. That was your personal opinion, and not a decision by the group... currently I do not believe any of todays user agents could pass a test suite of the XHR object, if that's the case then I think it's difficult to claim that we're defining a common subset that authors can rely on. That may of course be fine, but if it is then we should stop pretending we're trying to define what people can rely on. My view is that like Moz's (null) bug, we should make it a SHOULD so authors know they cannot rely on the behaviour currently. Jim.
Re: ACTION-51: XMLHttpRequest and 403
On Mon, 20 Mar 2006 08:33:35 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: I tested what mozilla does when receiving a statuscode of 403. We basically do the same as for a 200, except that xhr.status returns 403. The onreadystatechange handler fires as normal and both xhr.responseXML and xhr.responseText is set as normal. A testcase can be found at http://people.mozilla.com/~sicking/testcases/xhr-header.html For XHR2 it would be interesting to know if you invoke .onload or .onerror and if you think that can be changed. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-148: responseText and encoding
On Sun, 14 May 2006 14:35:16 +0200, Jim Ley [EMAIL PROTECTED] wrote: That was your personal opinion, and not a decision by the group... currently I do not believe any of todays user agents could pass a test suite of the XHR object, if that's the case then I think it's difficult to claim that we're defining a common subset that authors can rely on. That may of course be fine, but if it is then we should stop pretending we're trying to define what people can rely on. My view is that like Moz's (null) bug, we should make it a SHOULD so authors know they cannot rely on the behaviour currently. During the F2F (again, minutes are not yet released) the group agreed upon not having this reliable baseline approach as it didn't work out. Therefore Moz's (null) bug is now a MUST and this is too. That's also the reason we made XMLHttpRequest an EventTarget and introduced the readystatechange event. There was an additional resolution on a feature freeze so no more features will be added, but all features that are added will be sufficiently defined to be interoperable implementable in browsers. I hope that clarifies things and I also hope you can attend next meeting :-) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR constructor example
On Sun, 14 May 2006 14:05:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: var request = new XMLHttpRequest(); Given that it doesn't have to be a request I think 'r' is saver or perhaps just 'x'... Please don't use single letter variable names for anything but loop index variables (in languages that require those), it's generally considerd quite bad practice. Sure, give a me a sensible suggestion and I'll take it. Given recent discussions (you can post as well as retrieve) I'm not sure the original suggestion `var request` makes sense. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
ACTION-139: the IDL is non-normative
Used text: A more complete description of what can be done with codeXMLHttpRequest/code can be found in the abbr title=Interface Definition LanguageIDL/abbr below and its associated details. The IDL is non-normative and does not intend to conform to [OMGIDL]. Only the language bindings are normative. Also removed http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#xmlhttprequest the second editorial note regarding drafting up a note and all that. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: ACTION-148: responseText and encoding
Anne van Kesteren [EMAIL PROTECTED] During the F2F (again, minutes are not yet released) the group agreed upon not having this reliable baseline approach as it didn't work out. Aha, great! that makes a lot of stuff simpler! I'm happy with the MUST now I hope that clarifies things and I also hope you can attend next meeting :-) Well it's an interesting place... so I think it's probably likely :-) Jim.
Re: ACTION-87: Selectors API
On Wed, 22 Mar 2006 15:45:21 +0100, Jim Ley [EMAIL PROTECTED] wrote: Fair enough, here are the requirements for the name: * short * simple Why are these requirements for the name, no other DOM names are short and simple, they're clear and unambiguous, I'd say they were the requirements. If people want to use shorter names they understand in their closed world the $x() approach is perfectly simple for them (although discouraged by ECMA of course). This has been noted as an open issue. The reason is performance. Then one 1 method with an optional limit is ,uch better, it optimises for all situations when the author knows how many they're interested in, rather than 1 special case. I don't see why the 1 case is that much more special than the N case - as I say gEBI meets most of the 1 cases. The 1 case returns a Node as opposed to a StaticNodeList. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [comment] XMLHttpRequest Object - no interoperable implementations
Le 06-05-14 à 20:21, Anne van Kesteren a écrit : On Wed, 26 Apr 2006 07:10:51 +0200, Karl Dubost [EMAIL PROTECTED] wrote: The specification is here to set what is the correct behavior for the technology. Certainly there will be problems of interoperability, because of the history of the development. But I believe that a complete Test Suite should help to solve these issues by showing, don't tell what is the correct behavior. I would suggest to suppress most in the sentence and believe. The sentence contains also a prose which might be obsolete after a few years as it is only valid now. Perhaps we should move this to the history section, if we really need one (see other reply)? Yes it could be a solution And would satisfy your comment? We're planning on doing this for the next draft. Yes. :) Bis repetita. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: XMLHttpRequest Object feedback
* Anne van Kesteren wrote: Internet Explorer removed support for illegal HTTP URLs such as the one you've provided above because it has been abused too much in phishing mails. For other schemes where this is perfectly valid, like ftp, it works just fine in Internet Explorer. What does IE does in such cases and do we want the draft to reflect that? Internet Explorer 6 and 7 correctly discourage coding practices that are in violation of RFC 2616 and raises an exception on an attempt to open() such a URL. Opera9 and Firefox encourage incorrect and non-interoperable coding practices and use the specified user name and password if and when challenged for them by the server, contrary to the draft which re- quires not to respond to a challenge. We should * clearly point out that specification of user name and/or password in the URL depends on the URL scheme and for HTTP this is not allowed per RFC 2616 * define password and user name handling in terms of where to get those from when challenged for them (e.g., if cross-protocol re- quests are supported and an initial HTTP request yields in a 301 with Location: ftp://user:[EMAIL PROTECTED] you'd use those instead of something specified on open() or the initial URL). * not prohibit properly responding to a 401 challenge * specify error handling for unsupported URLs * specify error handling when If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security or infinite loop precautions) cannot be satisfied due to other reasons, like a redirect to an unsupported URL scheme and all sorts of other things... -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
XMLHttpRequest request bodies (was: Re: Issue: request bodies)
On Mon, 24 Apr 2006 21:15:36 +0200, Mark Baker [EMAIL PROTECTED] wrote: On 4/22/06, Maciej Stachowiak [EMAIL PROTECTED] wrote: Current implementations silently ignore the body in this case. FWIW, I decided to test this. As it turns out, IE and Firefox on WinXP pass bodies on all methods except GET (actually, I couldn't test GET on IE - it would only send POST!), and Opera passes them only with POST (and doesn't support PUT?!). That's all the browsers I have access to right now. http://www.markbaker.ca/2006/XHRTests/ So I have no strong opinions about this, but my suggestion would be to say that the data passed to send() is always used as the entity body, if present, unless the method argument is GET in which case it's dropped. Any objections? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR constructor example
On Sun, 14 May 2006, Anne van Kesteren wrote: On Sun, 14 May 2006 14:05:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: var request = new XMLHttpRequest(); Given that it doesn't have to be a request I think 'r' is saver or perhaps just 'x'... Please don't use single letter variable names for anything but loop index variables (in languages that require those), it's generally considerd quite bad practice. Sure, give a me a sensible suggestion and I'll take it. Given recent discussions (you can post as well as retrieve) I'm not sure the original suggestion `var request` makes sense. Does the example do a request? If so, 'request' is fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
