Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Ian Hickson wrote: On Tue, 17 Jun 2008, Zhenbin Xu wrote: I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx Oh, I assumed Sunava meant a conforming Document object was returned. A parseError-type object would be what I had in mind, yes. However, if we do this, then we should specify it. If we don't specify it, I'd rather have an exception. The spec can simply state that a conforming document object is returned, which includes out-of-band error information. This is what IE does today and is a very reasonable approach that allows rich error information for debugging. I don't believe it is conforming for Document objects to have parseError attributes, but I could be mistaken -- is there a spec for parseError? Even if there isn't, though, I agree that it is a generally good solution to the problem, I'm just saying that we should specify it, so that UAs can be standards-compliant and support it interoperably. I think we have two choices for how to handle parse errors here: 1. Mandate that a Document object containing a .parseError property is returned for .responseXML 2. Mandate that null is returned I think some hodgepodge solution of the two is likely just going to be harder to code against for developers. Are we comfortable adding the .parseError object to the XHR spec? Feels like spec creep to me unfortunately. / Jonas
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Zhenbin Xu wrote: The issue of return null or an exception is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way. Please note that it is not a goal for the spec to be written in such a way that all existing browsers are conforming to the spec. It turned out that it was impossible to write a spec with that goal while still keeping the spec useful. So we no longer try to accomodate all browsers, but instead write a spec that leads to interoperability between browsers. We would certainly love to have the spec change to MUST throw INVALID_STATE_ERR exception, which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if status is not available. responseText and responseXML are the outlier in the spec. Personally I think it makes more sense to return 'null' from .responseXML. We at mozilla have not had any interoperability problems with this behavior. Exceptions are better left for exceptional circumstances. However I can't say that I think the behavior is very important to me one way or another, as long as it's usefully defined. Best Regards, Jonas Sicking
Re: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]
Sunava Dutta wrote: Woo hooo, my first mail to the new webapps alias! -:) Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft. I've also addressed the questions members raised in the FAQ. Thanks Sunava, I look forward to reading this once it is available in an acceptable license. However, I would further hope that you are able to discuss the feedback that are sure to be raised? As with your initial feedback, much of the results of these discussions will also require research and so it is good if we can get as much done before the face to face as possible. As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July. Yes, though I do want to point out that there are many other issues too to discuss at the F2F other than microsofts feedback. Speaking of which, do we have an agenda yet for the F2F meeting? Look forward to hosting the members here in Redmond. Looking forward to seeing you there! Best Regards, Jonas Sicking
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
_http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_ The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I’d pre fer if the spec says *“*MUST return null OR an exception*”* otherwise I fear sites today will be broken. How would that help sites that expect an exception, since it would still be conforming for the UA to return null? If anything, your proposal seems to make it harder for sites to code against the spec. / Jonas
Re: DOML3: ACTION-266: TRAVIS - Test addEventListener vs onFoo attribute
Travis Leithead wrote: Interesting findings (mostly related to IE): This test tries to define if the HTML event handlers (onFoo) are linked to the add/removeEventListener APIs in any way (or to define what the relationship is). Browsers tested: Opera 9.25, Firefox 3 RC1, IE8 Beta1, Safari 3.1.1. (on IE, I substituted attach/detachEvent for add/removeEventListener) The findings appear to indicate that: 1. All tested browsers follow a basic model in that an HTML event handler is maintained separately (perhaps in a separate queue) from event handlers attached via programmatic means (e.g., addEventListener/attachEvent). This can be verified by adding an HTML event handler and then trying to delete the reference to its DOM attribute via removeEventListener. This is not true. You are assuming that the EventListener object used for onfoo attributes is the onfoo object itself. This is not the case in firefox, nor would I expect it to be the case anywhere else. Instead we create a separate EventListener object which wraps the onfoo object and deals with things like calling .preventDefault() if the onfoo object returns false. It also does lazy compilation when onfoo is set via setAttribute(onfoo, your code here); In firefox i think onfoo listeners do go in the same list as other event listeners, however you can't get to the EventListener object itself, so you won't be able to remove it using removeEventListener. A better way to test for this would be something like: myElem.addEventListener(click, listener1, false); myElem.onclick = listener2; myElem.addEventListener(click, listener3, false); And then check in which order the three listeners are called. If attribute listeners end up in the same list as normal listeners then the calling order should be: listener1, listener2, listener3. In addition to this basic conclusion, there were a few discrepencies in event handling that should be noted: * IE/Firefox/Opera all keep a reference alive to the HTML event handler via the element's 'onclick' DOM attribute even after the content attribute has been removed. Hmm.. this sounds like a bug to me. I would have expected .removeAttribute(onclick) to remove the .onclick attribute. / Jonas
Re: Note for DOM L3 Core SE
Maciej Stachowiak wrote: On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote: While implementing some improvements to getAttribute in IE8, we actually checked in code that is conformant to what the spec says about the return value: Return Value DOMString The Attr value as a string, or the empty string if that attribute does not have a specified or default value Once this code was in, we immediately hit app and site compat problems because we always returned a string--an empty string--if the attribute [did] not have a specified or default value. As it turns out in practice, all browsers actually implement this a slightly different way: they return the value as a string, or null if the attribute does not have a specified or default value. In other words, if there is no entry for the requested attribute in the NamedNodeMap, then null is returned. IE8 is being fixed to be conformant with what everyone else has implemented, I just thought I would pass this along to whomever is doing the DOM L3 Core Second Edition so that it might be recorded in that spec, an errata, or so that we can discuss. Anne and I suggested an errata for this a few years back, but the DOM folks were not receptive at the time, out of consideration for server-side Java DOM implementations: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0011.html http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0025.html See the thread for more discussion. I also at the time raised another compatibility issue that I thought should be fixed in errata: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0024.html The short version is that DOM forbids inserting nodes into a different document than their ownerDocument, but browsers allow it (in at least some cases). Yup, this is a bad situation indeed. Basically browsers are stuck with no good way out: Be compatible with the spec, or be compatible with the web. Of course any serious web browser is going to choose the latter. / Jonas
Re: Proposed errata for DOM2 Range regarding insertNode()
Ian Hickson wrote: Chaals, please see the end of this message. On Wed, 28 May 2008, Jonas Sicking wrote: It seems to me that everyone agrees that insertNode() was always intended to insert a node _into_ the range, and that the collapsed case was simply lost between the cracks when the DOM WG was writing the spec (much as was interaction with mutation events, for instance). Everyone who? And based on what? I don't see anything in the spec that suggests that. And as Olli pointed out there is clearly language in the spec that indicates that the inserted node would be after the range in the collapsed case. Well, everyone except you and Olli apparently. :-) Who is everyone? I've only seen you stating that the spec can be interpreted different ways after Olli pointed out what the definition of context tree is. Do you really think that it was intended for insertNode() to act differently when the range was collapsed than when the range wasn't collapsed, with respect to whether the inserted node ends up in the range or not? Act differently is a matter of how you view it. I guess I'm fine with making the change to the spec, but it would be a change and not an errata. I'm not sure what the distinction is. W3C has in the past been very reluctant to making changes to specs, even when specs have been incompatible with the web. If we decide that it's ok to make functional changes to the spec we're opening the flood gates for many more changes than merely clarifications. / Jonas
Re: Dedicated Geolocation List and Channel
For the record: Where the discussion takes place is of little importance to me and mozilla. It would make sense to me to do it here, but I'm just as happy to discuss it elsewhere too. So I don't prefer it one place or the other. / Jonas
Re: ElementTraversal progress?
Charles McCathieNevile wrote: On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Hi WebAPI fans! WebAPI! WebAPI! WebAPI! (Sorry) I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. It would be great to have this resolved pretty soon. The development cycle for our next release is quite short so if we want to add ElementTraversal to the release we would ideally like to see it more stable pretty soon. As before I'm still of the opinion that a .childElements NodeList would be a better solution. While I agree that it can be more complex to implement, I still think that the value vs. cost ratio still is quite good. One of the issues involved in a new, more complicated solution is precisely the one of stabilising the spec relatively quickly. Personally I think it seems better to go with what we have right now, and look at adding more in a seperate piece of work, so as to stabilise and finish the spec... I guess I would bow down to the majority vote here, though I really don't understand the more complicated argument as pretty much anything else we're talking about in this WG is more complicated than this feature. In mozilla we would actually even implement the .childElementCount property by keeping a hidden childNodes list internally. But that might be specific to the mozilla implementation. / Jonas
Re: setRequestHeader / Accept
Julian Reschke wrote: Anne van Kesteren wrote: ... We shouldn't let what webidl says dictate what we do one way or the other. It's just a spec for the idl language, not a recommendation for how interfaces should behave. null/undefined are not really part of the setRequestHeader() method. We just need to deal with them somehow and doing what similar APIs do in such cases makes sense. ... Such as xhr.send(null)? Yes, xhr.send(null) will send an empty body rather than one containing null. / Jonas
Re: setRequestHeader / Accept
Anne van Kesteren wrote: On Sun, 25 May 2008 20:40:48 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Agreed. We have in the past said that in the cases where it doesn't seem like the web is depending on a certain behavior one way or the other do what is most useful. I don't really think it matters much if null is treated as 'remove' or as 'do nothing', but appending 'null' seems pretty useless in pretty much all cases. It's pretty common behavior for a lot of APIs though Firefox seems to do it differently from everyone else quite often if I remember correctly. Yes, we never convert null to null since per spec null is a valid DOMString, so there should be no need to convert it at all. We shouldn't let what webidl says dictate what we do one way or the other. It's just a spec for the idl language, not a recommendation for how interfaces should behave. null/undefined are not really part of the setRequestHeader() method. We just need to deal with them somehow and doing what similar APIs do in such cases makes sense. Agreed, but I think defining them to turn null into null is a weird given that we can just leave it as null. If we should turn it into anything it should be the empty string as that seems to me as what makes sense. FWIW I think the webidl spec should be changed here, but i'll raise that in a thread for that spec. I think it makes sense for Web IDL to specify the most common behavior as default. Agreed, but I think we disagree on what most common behaviour is :) / Jonas
ElementTraversal progress?
Hi WebAPI fans! I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. It would be great to have this resolved pretty soon. The development cycle for our next release is quite short so if we want to add ElementTraversal to the release we would ideally like to see it more stable pretty soon. As before I'm still of the opinion that a .childElements NodeList would be a better solution. While I agree that it can be more complex to implement, I still think that the value vs. cost ratio still is quite good. Best Regards, Jonas Sicking
Re: [whatwg] The iframe element and sandboxing ideas
On Mon, 23 Apr 2007, Jonas Sicking wrote: There's a big difference to that and to what I'm proposing. With what's in bug 80713 you're still limited to a box that basically doesn't take part of the outer page at all. For example in the table example in my original post the headers of the table would not resize to fit the column sizes in the includeed table. Woah. That's far more radical. I have no idea how to do that. How would you make the parser not generate the implied elements and switch straight to the in table mode? How would you make the CSS model work with this? How would you define conformance for the document fragments? The parser questions here are interesting for sure, but I believe they could be solved. One way to solve the don't make the parser switch into mode X when it hits the iframe would be to teach the parser about include (or iframe seamless, or iframe include, or whatever it'll be called). That is pretty ugly though. One way to solve the fragment issue would be to say that the inner document always has to be a full document, and then use a fragment identifier to point to the contents of a table. The CSS model is simpler. XBL deals with exactly the same problem of combining multiple DOMs into a single flattened tree on which CSS is applied. I'm still intending to do some testing with this idea once I get more time. A lot of the implementation details have to be solved for XBL anyway. / Jonas
Re: Moving forward with XHR2 and AC
Thomas Roessler wrote: On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote: What I suggest is that we prohibit the Access-Control-Policy-Path header from being used on URIs that include the string ..\, in escaped or unescaped form. One worry with this is if there are encodings which put the '.' or '\' characters to other codepoints than 2E and 5C respectively. I.e. would we need to forbid its use on URIs other than ones containing That sounds like perpetuating a bad hack in a spec. I'd rather see us say -- in a note somewhere in the spec -- that servers will want to be careful, and will want to, e.g., configure their respective web application firewall to prevent this attack from occuring. That's very different from having specific client conformance requirements around this kind of server behavior. I really dislike it too, but just putting a be careful note in the spec isn't going to help anyone. If we don't put this in the spec I suspect that in reality this is something that implementations are going to want to do anyway. I guess I'm fine with having this as a non-normative note to ensure that implementations that want to be on the safe side can. But at that point we might as well enforce it in the spec too so that sites can rely on it. / Jonas
Re: [WebIDL] Passing null and undefined to DOMString things
It sounds like a bad idea to me that the default behavior for DOMString should be that null is converted to null. I can't think of a single case where that is what you want to do. Granted, this is partially due to a javascript spec bug, null really should have serialized to rather than null. Since DOM Level 1 DOMStrings have had null as a legal value, so when passing null to a string argument there is usually no need to do any conversion. When passing null to a [NotNull] string argument I think we should do the same thing as when passing null to any other [NotNull] argument, which IMHO should mean throwing. Though looking at the spec it no longer looks possible to say that a function excepting an object doesn't want null. Was that removed or was it never there? I thought that was how this whole thing started, so that we could for example mark up that Node.appendChild does not accept null as a valid argument. / Jonas Cameron McCormack wrote: I’ve made DOMString an intrinsic type in the IDL now (to avoid the “polite fiction”, as Maciej put it ☺). I’ve also replaced [NoNull] with [Null] and [Undefined], which can be used to specify how null and undefined are treated when passed as an operation argument or assigned to an attribute. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73content-type=text/html;%20charset=utf-8#idl-DOMString http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73content-type=text/html;%20charset=utf-8#Null http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.73content-type=text/html;%20charset=utf-8#Undefined Cameron McCormack: [treating null as ] Maciej Stachowiak: It needs to for many standard DOM methods. Most core DOM methods that take namespaces treat a null namespaceURI or prefix parameter the same as the empty string, not the same as the string null. I still think that for namespace URIs, the null value is what represents no namespace, while can just be used as an alias for this. This is what DOM 3 Core says: Applications should use the value null as the namespaceURI parameter for methods if they wish to have no namespace. In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null. This is true even though the DOM does no lexical checking of URIs. — http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations Maciej Stachowiak: I think DOM properties (and sometimes methods and function arguments) vary on this. Some use the raw ECMAScript ToString algorithm. Others additionally map the null value to the empty string instead of null. Still others map the undefined value to undefined. Some do both. I am pretty sure that for compatibility reasons you can't just do the same for each, so we may as well just define and test the legacy behavior for each one. Whatever is most common can be the default, and others can be marked up in the IDL appropriately. Ian Hickson: For both DOMString attributes and DOMString arguments, we have the following ways to handle null and undefined: … I think what we need is for WebIDL to have annotations for these cases, which can be prefixed in front of any occurance of DOMString in any IDL block, and then we can work down the APIs and check each DOMString occurance and work out which the UAs are doing. Say: [Null=Null, Undefined=Null] [Null=Null, Undefined=Empty] [Null=Empty, Undefined=Empty] [Null=Null, Undefined=String] [Null=Empty, Undefined=String] [Null=String, Undefined=String] ...so that we can do, e.g.: Window open([Null=String, Undefined=String] in DOMString url, [Null=String, Undefined=Empty] in DOMString name, [Null=Empty, Undefined=Empty] in DOMString features); ...or whatever is appropriate. I have replaced [NoNull] with [Null] and [Undefined]. The default behaviour for both null and undefined is to stringify, since that seemed to be most common in some (not completely extensive) tests that I did: http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=061 http://mcc.id.au/2007/05/binding-tests/tests/test.pl?id=062 So now you can specify [Null=Null], [Null=Empty], [Undefined=Null], [Undefined=Empty]. You cannot specify stringification though; that’s just the behaviour if the extended attribute is omitted. Although stringifying null to null is more common than passing it through, I sort of feel like [Null=Null] should be the default, since I still think of null being one of the values in the DOMString type. But at least as it is now, the two extended attributes are consistent (they both take either Null or Empty). Cameron McCormack: Should the Bindings spec require that the constructor return an object that implements that interface? Anne van Kesteren: That would make sense I think.
Re: Proposal to work on Geolocation
On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I could not find record of any such objection in the Advisory Committee mailing list archives, or any record of an official W3C decision on this point. As Team contact, could you please explain who made this decision and on what basis? In which case I presume that someone used their ability to reply to the Team privately instead of being open about what they wanted. This disturbs me a little since it increases the resources and coordination required, IMHO, to do what is a pretty simple piece of work. I think you may be overstating how simple this is, for what it's worth. Exposing coordinates sounds simple, sure... but the security and privacy implications are stickier, as is the legal landscape (both in terms of privacy laws and of IPR). I think this group is doing a lot of work which involves privacy issues, with more specs concerning them coming, so dealing with those would be no new task. Dealing with IPR issues would be something we haven't done though. Though given todays patent law, it seems like something that we likely have to deal with sooner or later no matter what. The big missing piece would be geolocation itself I would say :) All in all I would be in favor of doing that spec in this WG. / Jonas
Re: XHR header blacklist rationale
I also made it clear that the user agent is not to set any headers other than those on that list and those permitted to be set if the author has not set them (as explained under the send() algorithm). So, why are the headers below on the list? * Accept-Charset * Accept-Encoding I do see a reason why a UA wouldn't want content to set these. Which charsets and encoding a UA supports is currently very UA dependent. Currently this is ok since it's a feature not exposed to web content, but rather just an interface between the server and the UA. If web content can set these headers it is highly likely that pages will inadvertently create UA dependent pages that work if the UA supports some encodings, but break in UAs that don't. It would effectively force all UAs to support some standard set of encodings in order to work with the web. * Expect Don't know much about this header so i'll let others speak here. * Referer * User-Agent These should absolutely not be under control of web content. The Referer header is used by some web servers for security checks so allowing this to be settable would work around that. Servers can't currently rely on the header being there due to some firewalls/proxies filtering it, however they can rely on it being true when it is there. The User-Agent is used a lot for logging and measuring various aspects (OS, UA, etc) of the user base for a site. Allowing this to be spoofed by a web page would severely reduce its usefulness. You cite in a different mail that you want to be able to set this to work around servers that send different content based to different UAs based on this header. However if we let this header be set by web content then servers would not be able to rely on the User-Agent header and would likely start using even worse mechanisms. / Jonas
Re: XHR header blacklist rationale
Julian Reschke wrote: Jonas Sicking wrote: These should absolutely not be under control of web content. The Referer header is used by some web servers for security checks so allowing this to be settable would work around that. Servers can't currently rely on the header being there due to some firewalls/proxies filtering it, however they can rely on it being true when it is there. The User-Agent is used a lot for logging and measuring various aspects (OS, UA, etc) of the user base for a site. Allowing this to be spoofed by a web page would severely reduce its usefulness. You cite in a different mail that you want to be able to set this to work around servers that send different content based to different UAs based on this header. However if we let this header be set by web content then servers would not be able to rely on the User-Agent header and would likely start using even worse mechanisms. Microsoft's ActiveX version of XMLHTTPRequest definitively lets clients set it. I know it, because it was needed to override the UA header, so that servers would do proper authentication instead of form-based login. Not sure about what the native implementations do today, but I think we need to make sure that the XHR spec doesn't break use cases that work today. I assume that by it you mean the User-Agent header? Looking at the code it does indeed look like we let you set that header, which greatly surprises me. My gut feeling though is that we want sites to be able to rely on the UA header for logging. I'm fine with breaking use cases that work today if we do it to improve security. The User-Agent header isn't strictly security, but it's close to. / Jonas
Re: Moving forward with XHR2 and AC
Anne van Kesteren wrote: I changed my mind on several things below. On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Anne, can you summarise what needs doing to XHR2 and AC to move them forwards to last call? Is there a list of outstanding comments anywhere? XMLHttpRequest Level 2 * Depends on XMLHttpRequest Level 1 feedback: http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2 * It needs an introduction at some point. (Though not per se for Last Call I suppose.) This is both still true though I made some progress incorperating feedback. (Need to make sure everything relevant made XMLHttpRequest 2 too though. Access Control for Cross-Site Requests * Need to deal with Access-Control-Policy-Path normalization Done. I think we do need to deal with this. Just leaving it be will I think will cause exploitable servers out there. * Need to figure out if we want the server to whitelist headers/methods (we had methods before and then dropped it) I changed my mind on this. Given the reply from Björn in particular I don't think there's anything that needs to be done here. I strongly disagree here. Sorry about being slow to reply, will make sure that happens today. * Need to figure out if we want the server to opt in to cookies/credentials I rejected this proposal in another e-mail. Same thing here. / Jonas
Re: setRequestHeader / Accept
Julian Reschke wrote: Anne van Kesteren wrote: On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: Per the updated specification which uses Web IDL IE and Safari are conformant here. (null and undefined are simply stringified.) Not terrible useful, I would say. Is that something we have to live with because of the IDL definition??? It matches two implementations and is the default behavior for null/undefined when passed to something that accepts a string. Apparently existing content does not rely on it (FF gets away with implementing something that IMHO makes *much* more sense). So why standardize it at all, or, when doing so, select something that doesn't make sense in practice? Or are you claiming that people who set a header to null *really* want the specified behaviour? Agreed. We have in the past said that in the cases where it doesn't seem like the web is depending on a certain behavior one way or the other do what is most useful. I don't really think it matters much if null is treated as 'remove' or as 'do nothing', but appending 'null' seems pretty useless in pretty much all cases. We shouldn't let what webidl says dictate what we do one way or the other. It's just a spec for the idl language, not a recommendation for how interfaces should behave. FWIW I think the webidl spec should be changed here, but i'll raise that in a thread for that spec. / Jonas
Re: IE Team's Proposal for Cross Site Requests
Chris Wilson wrote: Indeed, there has been a lot of back and forth on the topics of XDR and XHR2+AC over the last couple of weeks. As others have pointed out, it hasn't so much been a back-and-forth as much as the rest of the group asking Microsoft for detailed information and waiting for answers. This message is not attempting to set forth in detail all the objections we have had; Sunava will deliver that in a concise form. From the comments in various responses in this topic, it is clear that expectations are extremely high for the level of detail in those objections; I don't think expectations are extremely high. We simply want information that is detailed enough that it can be used as basis for technical discussions and changes to the spec. So far the input has mostly been We are worried about the security implications of AC+XHR and think XDR is safer. That is not enough to make any changes to the Access-Control spec to address those worries. The rest of the group does not even know *what* the worries are. that takes much time to prepare, and involves a number of people here across multiple teams. Some of these concerns are direct and technical, and might be fixed in the XHR2+AC draft; however, some of our most important concerns pertain to the approach of enabling cross-domain. Not really sure what this means, but I'm hoping that Sunava will explain in his email what these concerns are. Given that the whole Access-Control spec is about enabling cross-domain, saying that that is the part you have concerns with doesn't really narrow things down :) However, we feel the design of grafting cross-domain access on to the already-existing XHR system is dangerous, Why? The new-XDR-API vs. reuse-existing-XHR-API discussion does not seem related to security. Though given the lack of specifics so far there isn't much for me to go on here. and the current design is being arrived at by the method of discussing what developers want to do, then trying to make it safe, rather than starting with what is secure by principle and incrementally adding functionality. Experience has taught us it is much easier to ship a system that is secure by design and add functionality than try to secure a implementation after it ships by rolling back features. I don't know what you mean by secure by principal and secure by design here. Are you alluding to the fact that XDR can never send out requests that aren't possible already? If so, that seems like it would only be secure by design as far as securing the server goes. Not as far as protecting the users data goes, which seems just as important. I would argue that Access-Control is better at protecting the users data than XDR. Since XDR isn't built for transferring private data (since it doesn't send cookies) it forces web developers to develop their own mechanisms on top of XDR. Most likely many of these mechanisms are going to be less safe than Access-Control since they are unlikely to spend as much effort and expertise securing their mechanism compared to how much has been put into Access-Control. Removing a tool to do safe cross-site private data transfer doesn't mean that sites will stop doing it. It just means that they will use other mechanisms. For example, today the current XHR draft proposes to block a list of headers that are unsafe only in a cross-domain context; however, this is difficult to deploy since XHR has already shipped, and challenging to imagine that there are no other headers in use by servers anywhere around the world that might not be good to access. How would the fact that same-site XHR is already deployed affect how we can deploy cross-site XHR? Is your concern that sites today attempt to do cross-site XHR requests and rely on the fact that that throws? Also, is this a security concern, or a concern that AC+XHR will break existing pages? In our opinion, one of the fundamental problems with the XHR2+AC proposal is that it blithely reuses an already-existing API for same-domain communication, and then attempts to patch the cracks that appear when it is used to perform cross-domain transfers. Again, why is this a problem? Even if we were to go with the security model of XDR, I would strongly advocate that we would use XHR as the API to access this security model. The discussion about the security model and the discussion about the API seems like two orthogonal discussions to me (with the security model discussion being far more interesting), and I would prefer if we discussed them separately. We want to be extremely clear that XDR is most definitely NOT, in our opinion, a “slightly different API that solves nearly the same problem” – neither is it “different for no extra benefit.” [3] Nor is it an “incompatible proposal,” [4] Why? The fact that the two APIs are nearly identical seems to indicate that they are. But again, the API discussion seems separate from the security model one. As for the
Re: XHR LC comments
Sunava Dutta wrote: Inline... -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 3:14 PM To: Sunava Dutta Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG (public); IE8 Core AJAX SWAT Team Subject: Re: XHR LC comments Sunava Dutta wrote: setRequestHeader() currently simply is broken. We should deprecate it, and add new methods with well-defined semantics: - removeHeader(...) (or specify set with null to mean remove) - addHeader... - getHeader... Deprecating a method does not help implementations converge. Besides, for typical usage there's no issue in using this header at all. [Sunava Dutta] I agree with Anne here. Deprecating an existing implementations and re-engineering XHR is something we just cannot accept. This spec should be designed to reflect reality and seek interoperability for each and every single section/method/event with at least one (I think the W3C mandates two?) existing implementations. That does not mean the entire spec is aligned with FF or IE, but it should be harmonious at any instance with one existing implementation. There is absolutely no W3C mandate that a spec is compatible with any existing implementations in order to reach the earlier milestones in the standardization track. Not sure where you got that idea. It would be very strange if there was a requirement to have implementations in order to reach LC, when W3C is discouraging implementations at that stage. Also, I personally don't care at all which UAs the various features of spec is compatible with. Or if it's not compatible with any UA. What I care about is that the spec is compatible with the web, and in the cases where the web doesn't care, that it's as useful and simple as possible. / Jonas [Sunava Dutta] Compatible with the web sounds very nice and is something I think I share with you. I think you mean compatible with browsers who enable the technologies when you mean compatible with the web? No, I mean able to run the javascript that exists on pages on the web. So for example if there is an aspect to a feature that no, or very few, web pages use, then I don't think we need to pay attention to what UAs do today and instead make the best possible spec based on technical considerations. Figuring out what aspects webpages do or don't use is hard of course. But often there are indications as well as implementation experience. Getting back to more specifics, if we're talking about compatibility I absolutely believe the spec should be relevant to existing implementations. What do you mean by relevant to existing implementations. And why do you think that? I'm amenable to what Maciej said when he mentioned that in the case (I'm assuming this is a rarity) where the implementations are doing whacky things or doing nothing at all, it makes sense to work together to identify a way/solution that will allow for convergence. It is in fact quite common when you start looking at the details of the various features that implementations behave very differently. So in those details we should in my opinion use the strategy I described above. / Jonas
Re: IE Team's Proposal for Cross Site Requests
Sunava Dutta wrote: This message is not attempting to set forth in detail all the objections we have had; Sunava will deliver that in a concise form. Can you give us a ballpark ETA on this? [Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to be ready and available to the Web API by mid June in the latest. Wow, this is really bad news that we won't get this feedback until just two weeks before the face to face meeting. Especially given the numerous delays in getting this feedback in the past I am very worried that there will be further delays. Are you absolutely certain that won't happen again? Even just having two weeks in order to discuss this feedback prior to the meeting seems like very short on time. I would really encourage you to consider providing this feedback more promptly. I do not wish to attend a face to face meeting solely to discuss new feedback which we have not had the opportunity to research and cannot usefully discuss. I also hope to cover much more than microsofts feedback during the meeting. I don't think there should be any surprises here as we have communicated our concerns before. I most certainly do expect there to be plenty of surprises here. I and many others have had a very difficult time understanding the concerns that microsoft has had so I hope that most of what you will be providing will be new information. [Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure if AC is vulnerable to that but it certainly seems possible? The point here is that a number of developers won't ready the security notes on the docs and inadvertently expose their services. Solutions should be coded for the lowest common denominator. That's hard to understand given that most Web API participants are quite technical. http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html Please note that that article does not point out a single site that is in fact vulnerable. It does seem to say that 1 site out of fortune 500 and 2 out of the alexa top 100 sites has a wildcarded crossdomain.xml policy. It does not say if any of those sites actually host sensitive information. However I do agree that crossdomain.xml is a very interesting case study. We should make sure to study that and learn from any mistakes made there. [Sunava Dutta] If we can agree on the security principles (hopefully the F2F) hopefully a safe way to do AC can be developed. First off, i certainly hope that we will be discussing the security principles before the F2F. I am very glad to see that microsoft recently have become active on this mailing list and hope that that will not stop. The more we can discuss the issues before the F2F the more productive we can be at the meeting. These are certainly scenarios that this feature is useful for that's why we're proposed XDR alongside. Although we invented XHR here we've been concerned about using it cross domain as mentioned before. I think the uber point with CS-XHR is the behavior is different in the two modes (same site and cross domain). That's confusing enough. While this is certainly an interesting discussion to have, I'm not sure I see the security implications between using an old API with new restrictions vs. creating a new API. This rather simply seems like a DOM API issue rather than a security model issue. We desire this also. Specifics help illustrate points best. [Sunava Dutta] Again, specifics will be provided however I reiterate, don't expect a stream of specifics to ensure that solution is ready to ship. I'm not sure I follow what you are saying here. Is your email on June 15th not going to include enough specifics to be able to discuss needed changes to the spec? That would seem very very unfortunate. / Jonas
Re: [July 1-3] [face to face] Agenda?
Charles McCathieNevile wrote: On Tue, 13 May 2008 02:54:58 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich [EMAIL PROTECTED] wrote: Hello, I understood that prio 1 item on the july 1st-3rd agenda is going to be XHR2 (XDR... input). What other items are (known to be) on the agenda ? (probably 3 days are anyway just enough to finalize XHR) XHR and XHR2 (and friends and acquaintances) are the agenda as planned. I suspect that will eat 3 days :( If not, I would be looking for other small stuff we can do, or for stuff that people think is urgent for that meeting. (I would rather finish early, really, if possible). Are we planning on discussing Access-Control as well? Yeah, sorry. That goes with XHR2 in my mind. Access-Control is developed by a wholly different WG though (at least until the two groups merge). Has it been properly announced to the members, and other participants, of that WG that this meeting is taking place? / Jonas
Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1
var ns = http://www.w3.org/1999/xhtml svg=http://www.w3.org/2000/svg; .querySelector(p svg|svg, ns); Let ns be an empty hash map, where the key is the prefix and the value is the namespace uri. Tokenise the nsresolver string by splitting on whitespace. For each token: If there is an '=' character in the string: Split the string on the first '=' character Let prefix be the string before the '=' character Let uri be the string after the '=' character Otherwise, there is no '=' character: Let prefix be (the default namespace) Let uri be value of this token If ns[prefix] does not already exist: Let ns[prefix] = uri The problem with this proposal is that it makes it very painful to write code that grabs expressions out of a DOM tree (such as in an attribute value) and then uses the namespace mappings available at that part of the tree to do namespace resolution. With the NSResolver API that means that you can simply use node.lookupNamespaceURI() in your implementation. With a solution where a full dictionary is passed in (either through a string or a a dedicated namespacemapper hash) the implementation has to manually implement the full lookupNamespaceURI algorithm manually. Maciej Stachowiak wrote: The bottom line here is that we're trying to represent what should really be a simple dictionary with a function, and it creates all sorts of unnecessary complexity. I'm curious to know what sorts of unnecessary complexity that you are referring to here. Yes, implementing callbacks does require code. But I would imagine that every UA out there already has such code. If for no other reason in order to support DOM events. Are there additional complexities you are worried about? Or are you worried it might not be possible to reuse the infrastructure developed for the other callback points in the DOM? / Jonas
Re: [July 1-3] [face to face] Agenda?
Charles McCathieNevile wrote: On Sun, 11 May 2008 18:48:27 +0200, Jean-Yves Bitterlich [EMAIL PROTECTED] wrote: Hello, I understood that prio 1 item on the july 1st-3rd agenda is going to be XHR2 (XDR... input). What other items are (known to be) on the agenda ? (probably 3 days are anyway just enough to finalize XHR) XHR and XHR2 (and friends and acquaintances) are the agenda as planned. I suspect that will eat 3 days :( If not, I would be looking for other small stuff we can do, or for stuff that people think is urgent for that meeting. (I would rather finish early, really, if possible). Are we planning on discussing Access-Control as well? / Jonas
Re: [XHR] No way to tell a request originates from an XHR object
Bjoern Hoehrmann wrote: * Francois Daoust wrote: In the context of content transformation that is a problem because such HTTP messages should be passed untouched by the content transformation proxies: an XHR call involves that some client code will be run on receipt of the response, so any transformation is likely to break the content delivered by the device. We were wondering if that use case would not meet other similar use cases in other areas that would require an easy way to tell that a request originates from an XHR object. Possible solutions: 1. amending the User-Agent string to include an XHR-like string somewhere 2. defining an additional header such as X-Ajax-Engine [2] ... and hopefully better solutions we haven't thought about. It is usually better to indicate your requirements instead of what soft- ware you are using; for example, instead of XHR you might be using the WebClient in Microsoft's SilverLight, or you might be using no Ajax en- gine at all. So here you would instead indicate that the response should be as if it had Cache-Control: no-transform set. I will also note that just because the request is initiated by a browser that does not mean there is no script that breaks on transformed content (whether you load some XHTML document with an iframe or XHR is not all that relevant). You will ultimately have to rely on some cooperation on part of the author, or transform content only very conservatively. Yeah, I think this is better addressed in a spec for mobile UAs instead. Such a spec could recommend that UAs add a header, like the one Bjoern is proposing, in certain situations. Such as when XHR requests are made, or when XBL documents are fetched, or when document.load is used, etc. But like others, I would expect a lot of sites to break if transformations were done to them without their cooperation. This is why we have greacemonkey scripts as extensions, and not built in by default :) / Jonas
Re: Security Re: File IO...
Charles McCathieNevile wrote: On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote: Hi folks, Opera has a proposal for a specification that would revive (and supersede) the file upload API that has been lingering so long as a work item. In a nutshell, it provides the ability for a web application to get a filespace, by asking the user to identify such a space, and making it available to that application something like a virtual file system. I am concerned about the security implications of this proposal. File upload in HTML is based on the user explicitly selecting a particular file. This has relatively low security risk, since the user is choosing one specific file that he or she wishes to transmit, and all that can be done with that file is upload its bytes. However, this API grants much more power than that. Yep. That's the idea. Here are some of the more obvious security issues: [several obviously interesting things] 6) Despite clearly having major security considerations, the document has no Security Considerations section. Indeed. (It also has no table of contents). There are obviously security issues any time you give access to something like the filesystem. That said, there are valuable use cases for access to the filesystem. The idea of standardising this currently rough proposal is that we identify and deal with those. An obvious approach would be to limit availability of this to trusted content for some definition of that (and different browsers currently have different definitions). As a work item we can happily raise the security issues and provide guidance about what circumstances open what kinds of risk. Which is what we would like to do, as part of making the functionality available to application developers in some way. For what it's worth Firefox has no concept of trusted content. That is, other than the code that makes up firefox itself, but that obviously doesn't need to use any standardized APIs. / Jonas
Re: [SelectorsAPI] Thoughts on querySelectorAll
John Resig wrote: Hello Everyone - I just wanted to quickly pull together some of my thoughts concerning querySelectorAll. I've been asked by a number of people to provide my feedback here. Please forgive me if I've missed some previous discussions on the subject matter. There's three major points that I wanted to discuss: * DOMElement.querySelectorAll returning incorrect elements So am I understanding you right in that if we do provide the second issue (Combinator-rooted Queries) then that will resolve your concern about this issue? I do understand your concern that in most cases you probably don't want the selector matching to leak out of the node on which .querySelectorAll was called. But I think spec-wise it's easier if the problem can be solved by using the :root trick or some such. That way the Webapi WG doesn't have to define a pile of new behavior for general selector matching. The added bonus of the current matching is that it does allow for the selector to leak should you want that for whatever reason. The libraries out there would only need to prepend :root to whatever selector they were handed. Though rather than using :root I think it would be more appropriate to use :scope as has been proposed in other mails on this list. It's entirely possible that mozilla could include an implementation of that along with the initial querySelectorAll implementation (though perhaps under the name :-moz-scope) / Jonas
Re: [SelectorsAPI] Thoughts on querySelectorAll
The added bonus of the current matching is that it does allow for the selector to leak should you want that for whatever reason. This isn't really important since this result can already be achieved in another manner, using .compareDocumentPosition() or .contains() (in IE). However, leaving it broken by default because it would be hard to specify doesn't really seem to mesh well. True, though this would be significantly slower since the implementation would match against all nodes in the whole document, only to have many of them filtered out. / Jonas
Re: [SelectorsAPI] Thoughts on querySelectorAll
John Resig wrote: But that would mean that .querySelectorAll(:root div) would never match anything since :root (or :scope) could only match the element itself, which of course isn't a descendant. I was under the impression that within the context of a DOM element :root would be equivalent to the root element itself - not the document element. Right Thus these two would be equivalent (returning the same sets of elements): document.getElementById(test).getElementsByTagName(div) document.getElementById(test).querySelectorAll(:root div) If that's not the case then disregard all of the previous :root is a good solution talk, because that's what I was basing this on. There are two contrary statements in your proposal. :root matches the root element (i.e. the test element in your example) All simple selectors has to match a descendant of the element on which .querySelectorAll was called. Clearly the test node isn't a descendant of itself, so the :root part couldn't match anything. / Jonas
Re: [SelectorsAPI] Thoughts on querySelectorAll
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: The issue isn't what we define :scope to match in general. But rather that you are saying that only descendants of the context node are allowed to match the individual parts of the selector. It seems the issue rather is using a pseudo-class here rather than some other syntax. I would assume John would be just as happy if the syntax was, say, $self ... which would avoid the problem you discuss here. It's not so much fact that it's a pseudo-class, but rather that it's a simple selector (sorry dbaron, don't know the correct term) which $self would be too. Unless we're redefining the CSS parsing rules which would mean that we have a lot of work remaining. / Jonas
Re: Modal dialogs in HTML5
João Eiras wrote: Unless the page raises another dialog of course For that there are popup blockers. The user must click something for another popup to open. 2008/4/29, Bjoern Hoehrmann [EMAIL PROTECTED]: * João Eiras wrote: The user can easily and quickly close the dialog and then the main tab. Two clicks instead of one... don't be lasy :p. That's a non issue. Unless the page raises another dialog of course, either maliciously or due to a coding problem. Preventing that from happening would probably not be easy without some surprises. Popup blockers are there to try to mitigate an evilness that was added a long time ago in a more innocent (naive?) time. Lets not add more such evilness. It only forces ourselves to struggle to find decent mitigation techniques, and forces developers to try to deal our mitigation techniques. / Jonas
Re: [selectors-api] Handling :link and :visited Pseudo Classes
Bjoern Hoehrmann wrote: As for the suggestion that all links must match one or the other, that would disallow e.g. reporting accurate results for all visible links but omitting any invisble link. I don't think that should be disallowed. How so? All invisible links would match :link, all visible visited links would match :visited, all visible unvisited links would match :link. This would seem to make all links either match :link or :visited. Or am I misunderstanding what you mean by visible, that would be quite possible as I don't understand the point of treating visible and invisible links differently. / Jonas
Re: [selectors-api] Handling :link and :visited Pseudo Classes
Boris Zbarsky wrote: Lachlan Hunt wrote: I'm considering adjusting the spec to allow just two options, and making IE8's behaviour non-conforming. Either: 1. Match unvisited and visted links normally with :link and :visited, respecitively. 2. Match all links with :link, and no links with :visted (i.e. treat all links as unvisited) I think that you should just require that if the UA implements :link and :visited at all any link must match one or the other. Which one is up to the UA. That allows UAs to impose security policies as needed while still allowing authors to match all links with :link, :visited. This sounds like an excellent idea to me. / Jonas
Re: [DOML3Events] ACTION-267 Proposal for event iterator
Hallvord R. M. Steen wrote: On Wed, 09 Apr 2008 23:50:59 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I've been specifically requested to add such support into IE by various customers. Most of their use-cases involve script that is trying to 'clean-up' event handlers for which they did not set, and do not have a pre-existing handle to the function callback. Could you be more specific about the use cases? One use case that hasn't come up but may be better supported by other means: debugging. As far as I can see, there is no view in, say, Firebug that shows me an overview of event listeners added with addEventListener(). In many cases this would be very useful. (By better supported by other means I meant that an alternative would be to enable something like the proposed functionality in debug mode or debug builds only. It seems more useful to me personally to simply have it available though.) Like Boris points out, there is no need to expose debugging APIs to web pages. Browsers can expose those thorough internal APIs to their tools. There is no API to enabling stepping through javascript or breaking on all exceptions either. / Jonas
Re: [selectors-api] NSResolver moving nodes between documents
Bjoern Hoehrmann wrote: * Hallvord R. M. Steen wrote: What I've understood: it's proposed that if the custom lookupNamespaceURI function moves nodes between documents, the implementation trying to use the NSResolver (may|must) throw an error. I don't see why we can't specify that unless we specify when and how many times the resolver is invoked. That could be done, but it would have little benefit at a high cost (more specification text to read for everyone, more tests to write, implementations cannot choose some better behavior, ... versus more consistent implementation behavior in a rather hypothetical case of incorrect code). If the custom lookupNamespaceURI function moves nodes between documents, the implementation trying to use the NSResolver MUST throw an error. If there should be a rule for mutations of the document from inside the namespace resolver, it should cover all the mutations, not pick some un- usual case. Further note that implementations would still differ, e.g., consider the selector a|b c|d :not(*|*) Some implementations might resolve a,c, others c,a, and yet others none of the prefixes because they immediately saw it does not match anything. So I would find it preferable, if this needs to be addressed, that the prefix resolution is made predictable, so that all mutations from inside the resolver become predictable, or that the DOM is locked while the query is evaluated, or that all mutations result in an error, not just node movements between documents, but I don't think this needs to be de- fined at all. So I might be missing something, but I think we're making this issue a lot more complicated than it is. Why not simply specify that the querySelector implementation must execute in two steps: 1. Parse selector 2. Walk the DOM and create result using parsed selector. Step 1 will call the NSResolver, but must not walk the DOM Step 2 must not call the NSResolver. This way it is ok if the NSResolver mutates the DOM in any fashion. The result returned from the function will simply be based on what the DOM looks like after step 1 is done executing. Yes, we could in theory specify which order the prefixes must be resolved using the NSResolver, however I think it would be better to state that it's undefined and that resolvers shouldn't rely on this. This is effectively the state for XPath and I have never heard of that being a problem. I also have a hard time imagining that anyone would actually write code that depended on the call ordering. This should be the easiest solution for spec writers and implementors alike. And I don't think users will care either way. / Jonas
Re: [DOML3Events] ACTION-267 Proposal for event iterator
Doug Schepers wrote: Hi, Jonas- Jonas Sicking wrote (on 4/14/08 5:58 PM): Like Boris points out, there is no need to expose debugging APIs to web pages. Browsers can expose those thorough internal APIs to their tools. Actually, I've seen Web apps that allow creation and debugging of content, and I think that's a perfectly legitimate use case. I would like to have this list of event listeners available. So would the solution I provided in an earlier email provide enough of a solution to satisfy your use case? If you want generic debugging APIs exposed to content that would have a *lot* of security concerns. So my question is, how much value would such an API add, compared to the other solutions that are available, compared to the complexity of implementing this securely in a UA. Especially considered the total lack of any other debugging-specific APIs in UAs. / Jonas
Re: [selectors-api] NSResolver moving nodes between documents
Boris Zbarsky wrote: Jonas Sicking wrote: 1. Parse selector 2. Walk the DOM and create result using parsed selector. That seems like the obvious approach. This way it is ok if the NSResolver mutates the DOM in any fashion. The result returned from the function will simply be based on what the DOM looks like after step 1 is done executing. There's one security consideration here, though: Say at the end of the mutation the script that called querySelector is no longer same-origin with the node that the method was called on. What should happen? Immediate exception? Return the nodes but not allow the caller to actually access them? Something else? My gut feeling is that immediate exception is the right thing to be doing... So this generally can't happen, except through implementation specific quirks, no? I.e. a page can't create an NSResolver mutates nodes to the point where it no longer has access to the page. So since this would be implementation specific behavior, possibly due to security bugs, I think it's fine if the solution is also implementation specific and we wouldn't need to say anything in the spec. / Jonas
Re: [selectors-api] NSResolver moving nodes between documents
Jonas Sicking wrote: Boris Zbarsky wrote: Jonas Sicking wrote: 1. Parse selector 2. Walk the DOM and create result using parsed selector. That seems like the obvious approach. This way it is ok if the NSResolver mutates the DOM in any fashion. The result returned from the function will simply be based on what the DOM looks like after step 1 is done executing. There's one security consideration here, though: Say at the end of the mutation the script that called querySelector is no longer same-origin with the node that the method was called on. What should happen? Immediate exception? Return the nodes but not allow the caller to actually access them? Something else? My gut feeling is that immediate exception is the right thing to be doing... So this generally can't happen, except through implementation specific quirks, no? I.e. a page can't create an NSResolver mutates nodes to the point where it no longer has access to the page. Ugh, sorry, this should say: So this generally can't happen, except through implementation specific quirks, no? I.e. a page can't create an NSResolver which mutates nodes to the point where the page no longer has access to the nodes. So since this would be implementation specific behavior, possibly due to security bugs, I think it's fine if the solution is also implementation specific and we wouldn't need to say anything in the spec. / Jonas
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site =?ISO-8859-1?Q? Requests]?=
Jon Ferraiolo wrote: Thomas Roessler [EMAIL PROTECTED] wrote on 04/14/2008 08:21:50 AM: On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote: On the architecture side, Access Control is just plain wrong, with the PEP on the client instead of the server, which requires data to be sent along the pipe to the client, where the client is trusted to discard the data if the user isn't allowed to see the data; it is just plain architecturally wrong to transmit data that is not meant to be seen. This seems to confuse the attacker model a bit. It's not about the user not being permitted to see the data, it's about a web application from a different origin not being allowed to manipulate the data, even though the user is allowed to see the data. The comment in question wasn't about CSRF or other data-setting attacks on a server, but instead about how it is architecturally wrong to send data that ultimately will be thrown out when it reaches the client. If I was outside of the standards world and wrote some code that did this, I would be embarrassed to show such an implementation during a code walkthrough. The policy check should be done before the data is transmitted. XDR seems to force much more data to be transmitted only to be thrown away. In the case of site A loading data from site B the whole resource is first transferred from site B to the client. Only then does the client make the decision to throw that data away if site B hasn't allowed cross-site access to the data. This does not only force the whole resource to be transferred only to be thrown away, it also forces the PEP to be the client as the server is given absolutely no information about who site A is. / Jonas
Re: [selectors-api] NSResolver moving nodes between documents
Boris Zbarsky wrote: Jonas Sicking wrote: So this generally can't happen, except through implementation specific quirks, no? I.e. a page can't create an NSResolver mutates nodes to the point where it no longer has access to the page. Sure it can. Setting document.domain will do the trick, easily. Hmm.. good point. Though I still think that you basically have to intentionally shoot yourself in the foot for this to happen, and so it's a case that is unlikely to come up and cause interoperability issues. Leaving it explicitly undefined sounds like a good idea though. / Jonas
Re: [DOML3Events] ACTION-267 Proposal for event iterator
Travis Leithead wrote:
From your link, it appears the only reason this was dropped was because the
folks in discussion at the time thought the only use case for this feature was
Accessibility venders (ATs).
It wasn't just dropped because it wasn't needed (because AT doesn't need
to use DOM APIs). It was also dropped since it would mean that internal
code can not use the generic DOM APIs to add event listeners. This is
something that we do a lot in Firefox code and that is done by a lot of
Firefox extensions. See
http://lists.w3.org/Archives/Member/member-webapi/2006Feb/0301.html
and the followups.
I agree that this is something that we could work around if absolutely
needed. I'm definitely an advocate for not designing Web APIs for
internal consumers. However it is always a very nice bonus when public
APIs are also useful internally.
So I too would be interested in hearing more about the use cases here.
Could the following be used as a solution?
oldAddEL = EventTarget.prototype.addEventListener;
Node.prototype.addEventListener = function(type,
listener, useCapture) {
if (!this.getUserData(listeners)) {
this.setUserData(listeners, [], null);
}
this.getUserData(listeners).push(listener);
oldAddEL.call(this, type, listener, useCapture);
}
This should let the page access all listeners added to any node using
getUserData(listeners).
/ Jonas
Re: [DOML3Events] ACTION-267 Proposal for event iterator
Boris Zbarsky wrote: Jonas Sicking wrote: oldAddEL = EventTarget.prototype.addEventListener; Node.prototype.addEventListener = function(type, I should note that this wouldn't work in recent Geckos, by the way... I think it might actually, since addEventListener isn't on the nodes prototype chain normally. But in any case if the above didn't work it's a Gecko bug and not something we should design APIs around. / Jonas
Re: [XMLHttpRequest2] response headers for cross-site requests
Anne van Kesteren wrote: Currently XMLHttpRequest Level 2 has restrictions on getting response headers when doing a cross-site request. I have a feeling these may be an artifact of the slightly older model. getAllResponseHeaders() returns the empty string currently. getResponseHeader(header) returns null unless header is one of Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma. I think we should be able to change this. (Though we can't expose Set-Cookie and Set-Cookie2 obviously.) Any thoughts? (I bbc'ed the WAF WG list as there might be some people there interested in this. Please reply to the Web API WG list. I'll be happy when this work ends up in the same group soonish...) I'd wonder what the purprose of this is? I.e. what's the usecase? We don't want to allow access to cookie and authentication headers, right? Are you sure there are not anything else like it as well that authors won't unintentionally expose? / Jonas
Re: [Element Traversal LC] access to element by index
Jean-Yves Bitterlich wrote: A few alternatives were proposed here, referred below as (i) 'attribute NodeList childElements', (ii) 'Node item(index)' and (iii) xpath .querySelector. I personally like (iii) because it is powerful (or is it just queries that are powerful?), however it definitely belongs to another spec. Alternative (i) has its advantages and disadvantages that were also theoretically mentioned in this thread. However, from our experience in the mobile space and in particular given our implementations (optimized SVG and 280-DOM, both for Java-ME), it would cost extra memory and code execution: the implementation would need to create an object with very short life span (an instance of NodeList). It should hurt the performance on two fronts: extra garbage collection and extra code execution. On the other hand, if Elements would cache the NodeList object it will inevitably affect RAM footprint. Do you have any data on how much extra this footprint would be? It seems to me that it usually should be very small compared to the other things stored in a DOM, such as attribute values and text nodes, not to mention all rendering objects needed to display a web page. / Jonas
Re: [Element Traversal LC] access to element by index
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: I'm not following this argument at all. Neither would content that uses .globalStorage, .forms, .querySelector or anything else that's not in the SVG Tiny spec. We're trying to make a new API here, of course content that uses that API isn't going to work in implementations that don't support it. Look at this from the perspective of the SVG Working Group. The idea was simply that the element traversal feature defined in the SVG Tiny 1.2 CR would be put in a separate specification maintained by a separate WG and they would replace their definition with a reference to the new spec. If we add features to the specification they don't want to require of SVG Tiny 1.2 clients, they can no longer do that, they have to profile the specification and highlight, probably in both specifications, that the new feature is not necessarily available in SVG Tiny 1.2 clients, leading to complaints about the profiling and confusion among authors, who will use the feature in their supposedly Tiny 1.2 content because it happens to work in the clients they tested it in (but not in others). Both would be less so if the new feature is not added to this version of the element traversal specification, so I would expect them to say they are unhappy with the addition and, if the feature really has to be added, ask that it be added to some other specification. It's simply a problem you'll likely have to deal with when adopting the NodeList idea. Ah, thanks, that does explain the issue. Though I think that if we want the web to have a .childElements NodeList available then we have two options: 1. Add it to the ElementTraversal spec and have SVG Tiny say that they no longer require the full ElementTraversal spec. 2. Add it to a separate unrelated spec, such as HTML5. Result 2 doesn't seem any better than 1. The end result for both is that SVG tiny only require a certain set of properties, and with 2 we'd have to wait some undefined amount of time before getting it into an Rec, possibly of a spec that will have a much slower adoption rate. / Jonas
Re: [Element Traversal LC] access to element by index
If we're not 100% compatible with SVG, why would they oppose an improvement like the suggested one? Content that uses childElements[...] would not function correctly in SVG Tiny 1.2 implementations for no particularily good reason. I'm not following this argument at all. Neither would content that uses .globalStorage, .forms, .querySelector or anything else that's not in the SVG Tiny spec. We're trying to make a new API here, of course content that uses that API isn't going to work in implementations that don't support it. / Jonas
Re: [XHR2] onprogress Event issue
Julien Chaffraix wrote: Hi everyone, We are in the process of implementing XHR onprogress attribute on WebKit and arises a compatibility issue with the Firefox implementation. Currently the XHR2 draft specifies that we use the ProgressEvent interface for onprogress events whereas Firefox uses the DocumentLS LSProgressEvent interface. We are left wondering which way to go. Does someone know what the prospects are: will Firefox change its behavior in the future or should we ask for a modification of the draft? This is definitely a good question, one that I'd like to see addressed too. I think that if the spec remains as is Firefox would likely fire events that implements both the ProgressEvent interface and the LSProgressEvent interface, but encourage people to use the ProgressEvent interface. Possibly even by putting a message in the error console when the old interface properties are accessed. / Jonas
Re: [Element Traversal LC] access to element by index
Daniel Glazman wrote: I'm actually not sure. How often do authors want to get the third child without knowing anything more about it than that it's an element? Iterating through the kids (by means of ET or '.childNodes') gives you much more context information (what type of element it is, what it's bbox is, whether or not it has text/child content, etc.). Not trying to be a pain, but can you identify a concrete use case? [admin: please Cc me, I am not following this mailing-list] I probably has to use it in my daily code - find the n-th child element of another given element - at least a dozen times in the last fifteen days. Iterating through the kids is a for my point of view pure bloat compared to myFooElement.childElements.item(3)... I agree with Daniel, while I don't write a lot of javascript myself I've seen a number of cases like this in the javascript used to implement firefox: bar = foo.parentNode.parentNode.childNodes.item(3).firstChild; Basically I wonder why we wouldn't give access to items by index? Complexity of implementation really can't be an argument here, the amount of code to implement this is trivial, especially compared to all other things required by a browser or DOM implementation. Like Boris pointed out it's likely that an implementation could reuse existing code, but even if that isn't the case I would imagine that the code to implement this property is laughable compared to the code needed to draw an antialiased spline or implementing DOM events (part of which I use as a hiring interview question due to its complexity). I remember in the initial releases of gecko we got a lot of support questions from people wondering why their DOM-using code didn't work in Netscape when it worked in IE. The reason was that IE didn't create DOM nodes for whitespace-only nodes and so the DOM was significantly different and harder to figure out where your nodes lived. getElementById helped to some extent here, and I think that recent development of javascript libraries has helped a lot too. However if we are arguing that people should use those solutions there really is no need for the ElementTraversal spec at all. So I honestly can't understand the complexity argument at all. I think ElementTraversal is something that users really want and would be trivial to implement with or without .childElements. So there really is no need to cut corners and good arguments not to. / Jonas
Re: [Element Traversal LC] access to element by index
Henri Sivonen wrote: On Apr 2, 2008, at 12:44, Jonas Sicking wrote: And to what end? To use indexing instead of list-style iteration. Exactly. Something that I would imagine is quite commonly done. Note that we're not just talking iterating over a full DOM tree, we're also talking about navigating around in a DOM tree from one known specific node to another. It seems to me that allowing indexed access to children creates a similar kind of problem that allowing indexed access to strings by UTF-16 code unit has created. Allowing app code to index into platform structures that are most commonly forward-iterated seems like an anti-pattern in terms of what implementation constraints are placed if the impression that the app developer gets is that indexing has the performance properties of array access and that it is OK to write app code with that assumption. What makes you think that most users of the DOM-tree does forward-iteration? This is not my experience with the code I've seen. Rather it has been trying to get to specific nodes within a tree. The same argument can be made for .nextElementSibling, why give forward-iterating access into platform structures that are most commonly index-accessed? / Jonas
Re: [XHR2] onprogress Event issue
Anne van Kesteren wrote: On Wed, 02 Apr 2008 08:54:17 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: This is definitely a good question, one that I'd like to see addressed too. I think that if the spec remains as is Firefox would likely fire events that implements both the ProgressEvent interface and the LSProgressEvent interface, but encourage people to use the ProgressEvent interface. Possibly even by putting a message in the error console when the old interface properties are accessed. If we want a different interface I think the progress events specification should be changed. XMLHttpRequest Level 2 simply uses whatever Progress Events 1.0 defines at this point and I'd like to keep it that way. FWIW i'm fine with keeping things the way they are. Though there is definitely a risk that other vendors will have to implement the LSProgressEvent interface as well in order to support content out there that is written for firefox. But we're talking about two extra properties whose implementation will basically just be to forward to another property so I doubt that it's a big burden. / Jonas
Re: [Element Traversal LC] access to element by index
Daniel Glazman wrote: Jonas Sicking wrote: Bjoern Hoehrmann wrote: We could also standardize the popular .getChildrenByTagName() method, that would give the similar myFooElement.getChildrenByTagName(*)[3] This seems like an excellent idea. To do in addition to the ElementTraversal spec. I understand from Jonas's answer that he also never heard before of that popular getChildrenByTagName()... I hadn't, but I wouldn't expect to either since I'm not looking at toolkits that often. But I was serious about thinking that adding the function seems like a good idea. It's currently much too painful to navigate around in the DOM so it's something we should try to fix. / Jonas
Re: [Element Traversal LC] access to element by index
Bjoern Hoehrmann wrote: * Daniel Glazman wrote: 1. congrats for this spec, I love it ; I can't count how many times in page or chrome script I am filtering out nodes that are not element nodes. 2. the ElementTraversal interface has a |childElementCount| attribute but misses access to an individual childElement based on its index. That would be really useful. Two solutions here : a. you remove the childElementCount attribute in favor of a readonly attribute NodeListchildElements; and that NodeList has all we need It was the SVG Working Group that originally came up with the interface and they, as I understand it, decided against having any NodeList in the SVG Tiny 1.2 DOM. They rather introduced the interface to allow imple- mentations to discard some nodes like comments and text nodes with only white space while keeping compatibility with implementations that keep them. I would imagine they would be unhappy with such a change. I agree with Daniel here. I'm not really following your argument. Are we trying to keep compatibility with the SVG spec here? Is the interface as designed now 100% compatible with SVG? If we're not 100% compatible with SVG, why would they oppose an improvement like the suggested one? I don't see how having the suggested interface would affect if you can discard other nodes entirely or not, that seems to be more affected by the *other* interfaces in the various DOM specs (such as DOM L1 Core). If we don't provide a way to grab elements by index I don't really see a purpose of the childElementCount attribute. / Jonas
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
Sunava Dutta wrote: IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. We think there is a place for both implementations within the charter of the Web API. Here's a re-summary of why that I've extracted from our proposal and our responses. For more details please refer to our proposal and the mail conversations on the topic: - XDR is provably secure and does not introduce new surface area of attack compared to HTML Forms. Like Hixie raised, this has been shown to be untrue. The XDR proposal let you POST data with any content-type to intranet servers, something which is not possible today. - It's really simple to program against. I don't see that XDR is any simpler than access-control. To enable GET requests for XDR the server sends: XDomainRequestAllowed: 1 With access-control: Access-Control: allow * Neither of these look significantly simpler than the other. POST requests in XDR isn't safe (see above) so it's not really interesting to compare simplicity. Also, with XDR users have to learn a new API. With access-control you simply use the same APIs as you always have. - While the existing proposal can do what XDR does and more, it is complicated with XHR and also tricky to implement. It took me about 2 days to implement the majority of access-control. This went up to maybe a week as more features were added. This is hardly significant time for any UA vendor. As we mentioned before, authentication scenarios behave differently compared to XHR and so do headers. This is also untrue. When it comes to headers the difference between XHR and AC+XHR is much smaller than the difference between XHR and XDR. Authentication in XDR is significantly different from how authentication is done today as any authentication tokens have to be sent as part of the request body, so again XDR is much more different from XHR than AC+XHR is. Editing the policy also quickly gets tricky as the number of rules increase. For public data aggregation scenarios web developers would benefit from the simple and secure XDR object. Again, to get equivalent level of functionality the only difference is XDomainRequestAllowed: 1 vs Access-Control: allow * so I don't see how XDR is simpler than XHR. Yes, if you want to use a larger feature set than what is supplied by XDR things get more complicated. But that doesn't seem like a useful comparison. So all in all i'm opposed picking up XDR into W3C. It currently suffers from bad security issues which I suspect would make most UA vendors not want to implement it, and it's a less useful subset of a spec that is already in development. Best Regards, Jonas Sicking
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
Eric Lawrence wrote: Ian-- Thanks for sharing your opinions. I'd like to take the opportunity to clarify a few points of confusion. This is blatently untrue, a number of serious security problems with XDR have already been raised (such as the fact that it encourages content-type sniffing It's possible that you overlooked some mails on the thread? Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary. I think you are misunderstanding the issues Ian has raised. Since XDR does not let you set the Content-Type header, the server is in fact required to sniff the content type. How else would the server figure out the content type of the request body? Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server. As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative. I think you are misunderstanding the issues Ian has raised. The issue isn't that the server treats the Content-Type as authoritative and then trips over while trying to parse it, but rather that servers will sniff the content, misunderstand what content type it really is, and then do the wrong thing with it. Off the top of my head I don't really see any security issues with the sniffing (although sniffing is in general bad so I wouldn't be surprised if there are any), but rather it just doesn't seem like a very robust API and something that could loose out on functionality. When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms. In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform. As well as adding much less value. the fact that it encourages people to pass their credentials to untrusted third parties). XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not. In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication. Again, this is not the concern. The concern is sites that do want to transport private data. They are going to try to do this weather the browser provides the API meant for this or not. In fact, I would argue that XDR does encourage sending private data. Most use cases for POST that I can think of involves knowing who the data is coming from. Or have you had other use cases in mind? The simplest way to authenticate fetching private data using XDR is to ask the user for his/her credentials and then include that as part of the uri in a GET request. This has two problems. 1. It means that the user will have to give his/her credentials to the requesting site. This fosters a culture where you hand out your password to 3rd party sites, something that is really unsafe. 2. Including the credentials in the uri will most likely mean that it will get logged in various places along the way. For example proxies as well as browser extensions often track uris of loaded resources. Sure, you can say hey, we said you shouldn't fetch private data using XDR, it's your own fault for doing so. However that doesn't really help anyone. Additionally, it is not true that no authorization credentials is being sent. Intranet sites might authorize simply based on the fact that you can connect to the intranet server. I have still not seen anything in the XDR spec to prevent internet-interanet POSTs so this still seems to be the case. This can be contrasted with the CS-XHR proposal, in which credentials ARE automatically passed to 3rd party servers. But the credentials are kept away from the 3rd party site as well as kept out of server logs. It fails to address the majority of use cases for cross-domain data transfer on the Web. I think this will prove to be a difficult statement to prove one way or another. It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future. We absolutely agree that it is possible to define use cases that XDR does not accommodate. We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser. We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal. I definitely appreciate all the work that Microsoft has put into the spec, but am saddened that there was no mention about XDR in any of the numerous posts from anyone at microsoft. / Jonas
Re: IE Team's Proposal for Cross Site Requests
Laurens Holst wrote: Laurens Holst schreef: Or, if you really do not want to increase the attack surface, you should always send the content type application/x-www-form-urlencoded, and only allow request entities constructed through an API. Because servers only expect x-www-form-urlencoded and not text/plain, and servers might have parsing issues if the POST body is malformed, both leading to changes from what is currently possible with HTML and thus, security risks. Sorry, apparantly this is a misconception of mine, using encoding=text/plain you can apparantly already send arbitrary requests. So ignore this paragraph please :). The rest does still apply. By the way, I do not see how requiring servers to ignore the request entity content type and forcing them to do content sniffing makes things more secure, instead of less. Though to be honest I would really like to figure out a way to disable cross-site POSTs even from forms. CSRF is a big problem with tons of sites vulnerable today. So I'd really like to not perpetuate the model of allowing cross-site POSTs. An interesting first step in that direction would be to disallow cross-site text/plain posts since they are so rare that it'd likely not affect many sites. / Jonas
Re: [selectors-api] Why have two identical differently named interfaces?
Lachlan Hunt wrote: Anne van Kesteren wrote: On Fri, 14 Mar 2008 01:18:27 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: Maybe the best solution would be to add a :scope pseudo-element which is the target of the querySelectorAll call if not called on the document. That would allow old-school JS library semantics just by prepending :scope . :scope would also be nice for HTML5 style scoped. In the interest of getting this specification to CR sooner rather than later, I have decided not to include such a feature in this specification, but I think it is worth considering for a future extension. Sounds fine to me. But I still haven't heard anything regarding the original subject of this thread :) Is there a reason not to merge these two interfaces and also let DocumentFragments implement it? / Jonas
Re: IE Team's Proposal for Cross Site Requests
Also, if you do have reliable definitions of the Intranet/Internet/Restricted zones, what is the purpose of the XDomainRequestAllowed header since presumably all servers in a zone could just read data directly from each other without regard for the XDomainRequestAllowed header. / Jonas Jonas Sicking wrote: How do you define the Intranet, Internet, Restricted etc zones? Without correct definitions for these zones it seems possible to attack intranet servers by sending unsafe (such as POST or DELETE) requests to intranet servers from internet pages. I'd also recommend sending this to the web applications formats group since they have been working on a very similar security proposal. / Jonas Sunava Dutta wrote: Purpose XDR helps web developers to create secure mashups, replacing less secure or non-performant approaches, including SCRIPT SRC’ing content or IFRAME injection. Microsoft would like to submit XDR to the W3C for standardization so that other browsers can benefit from this technology. XDomainRequest (XDR) Table of Contents 1.0 Summary 2.0 Background: /Overview of how XDR allows cross site requests/ 3.0 API Documentation: /Lists the programming interface/methods/properties/ 4.0 Security Model Flowchart: /Highlights the security checks that IE8 makes for an XDR Request./ 5.0 Sample Site and Script: /For developers wishing to create an XDR page./ 6.0 Developer Benefits of using XDR: /Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity./ 7.0 Developer Release Notes: /A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do./ 1.0 Summary /With* Cross Domain Request* *(XDR)* developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1 http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html, 2 https://bugzilla.mozilla.org/show_bug.cgi?id=389508), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered http://blog.monstuff.com/archives/000302.html (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative./// 2.0 Background Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser. Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server. In IE8 web pages can simply make a cross domain data request within the browser using the new /XDomainRequest/ object instead of a server-to-server requests. Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a /xdomainrequest /object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a /XDomainRequest: 1 /header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true. For example, a server’s asp page includes the following response header: Response.AppendHeader(XDomainRequestAllowed,1); *Security note: *Cross domain requests are anonymous to protect user data, which means that servers cannot easily find out who is requesting data. As a result, you only want to request and respond with cross domain data that is not sensitive or personally identifiable. 3.0 API Documentation * * *Methods* Once you create a xdomainrequest object, you can use the /open
Re: IE Team's Proposal for Cross Site Requests
Can you describe what you mean by persistent allow design? / Jonas Chris Wilson wrote: Oops. Obviously, this was not to go to the whole group. I’ve been asked a lot, over the last week and a half, why we implemented XDR rather than the current cross-domain XHR proposals. The short version is, as Sunava discusses in the summary of this mail, that x-domain XHR (and Flash’s approach, et al) is subject to specific x-domain injection attacks because of its persistent-allow design. *From:* Chris Wilson *Sent:* Friday, March 14, 2008 11:00 AM *To:* Sunava Dutta; Web API WG (public) *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey *Subject:* RE: IE Team's Proposal for Cross Site Requests I’d move half the summary section up front to make it clear why we’re not wild about x-domain XHR. You need to lead with that. *From:* Sunava Dutta *Sent:* Thursday, March 13, 2008 8:47 PM *To:* Sunava Dutta; Web API WG (public) *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey *Subject:* IE Team's Proposal for Cross Site Requests Purpose XDR helps web developers to create secure mashups, replacing less secure or non-performant approaches, including SCRIPT SRC’ing content or IFRAME injection. Microsoft would like to submit XDR to the W3C for standardization so that other browsers can benefit from this technology. XDomainRequest (XDR) Table of Contents 1.0 Summary 2.0 Background: /Overview of how XDR allows cross site requests/ 3.0 API Documentation: /Lists the programming interface/methods/properties/ 4.0 Security Model Flowchart: /Highlights the security checks that IE8 makes for an XDR Request./ 5.0 Sample Site and Script: /For developers wishing to create an XDR page./ 6.0 Developer Benefits of using XDR: /Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity./ 7.0 Developer Release Notes: /A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do./ 1.0 Summary /With* Cross Domain Request* *(XDR)* developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1 http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html, 2 https://bugzilla.mozilla.org/show_bug.cgi?id=389508), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered http://blog.monstuff.com/archives/000302.html (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative./// 2.0 Background Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser. Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server. In IE8 web pages can simply make a cross domain data request within the browser using the new /XDomainRequest/ object instead of a server-to-server requests. Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a /xdomainrequest /object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a /XDomainRequest: 1 /header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true. For example, a server’s asp page includes the following response header:
Re: IE Team's Proposal for Cross Site Requests
Also, the OPTIONS request is there to prevent requests that XDR simply always allows, i.e. cross site requests using unsafe methods. So I'm not sure I see how XDR is safer in that regard here. I would be very interested to hear back on the two first emails I posted to this thread as they relate to this exact subject. / Jonas Jonas Sicking wrote: So the worry here is a scenario where an attacker tricks a user to go to evil.com which does an evil POST to webstore.com. And at the same time the attacker launches a DNS rebind attack on the user for the webstore.com domain name such that the OPTIONS request goes to an attacker controlled server which approves the POST, but then lets the actual post go to the real webstore.com server? If so, couldn't the user simply trick the user to go to webstore.com, and use a DNS rebind attack so that when webstore.com/ is fetched it returns a HTML page that contains script that uses normal XHR to do a POST to webstore.com. When the POST happens the attacker lets that go to the real webstore.com server. I.e. I don't see how Cross-site XHR in combination with DNS rebind attacks lets you do something that DNS rebind attacks doesn't already let you do on it's own. XXX = Cross-site Extensions to XHR. So basically XHR+AC spec. / Jonas Chris Wilson wrote: Yes, DNS rebinding is one of the major attack vectors I was talking about. If the access controls are negotiated independently of the actual request/response, this is nearly always a concern. (Yes, you could require follow-ups to go to the same IP address; that's both a pain to actually implement (because a high-level request needs low-level access; typically, I don't believe we need to know about the IP address at the XHR level) and somewhat confusing (because it will break if there's normal, permitted DNS round-robin going on, e.g.). Maciej, does XXX = XHR L2 or XDR? -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 1:25 PM To: Jonas Sicking Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey Subject: Re: IE Team's Proposal for Cross Site Requests On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote: Can you describe what you mean by persistent allow design? Anne and I discussed this comment on IRC. One possible flaw is that the OPTIONS request to guard against an unaware server receiving cross- domain POST or other methods is subject to a DNS rebinding attack (though this could be fixable by requiring the OPTIONS and the follow- up request to go to the same IP or something along those lines). I'm not sure if this is the vulnerability Chris had in mind. I don't think XXX has the same vulnerabilities as Flash though, because the access- control headers are not an out-of-band control file so the actual access control check can't be bypassed via DNS rebinding, only the method check. - Maciej / Jonas Chris Wilson wrote: Oops. Obviously, this was not to go to the whole group. I've been asked a lot, over the last week and a half, why we implemented XDR rather than the current cross-domain XHR proposals. The short version is, as Sunava discusses in the summary of this mail, that x-domain XHR (and Flash's approach, et al) is subject to specific x-domain injection attacks because of its persistent-allow design. *From:* Chris Wilson *Sent:* Friday, March 14, 2008 11:00 AM *To:* Sunava Dutta; Web API WG (public) *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey *Subject:* RE: IE Team's Proposal for Cross Site Requests I'd move half the summary section up front to make it clear why we're not wild about x-domain XHR. You need to lead with that. *From:* Sunava Dutta *Sent:* Thursday, March 13, 2008 8:47 PM *To:* Sunava Dutta; Web API WG (public) *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey *Subject:* IE Team's Proposal for Cross Site Requests Purpose XDR helps web developers to create secure mashups, replacing less secure or non-performant approaches, including SCRIPT SRC'ing content or IFRAME injection. Microsoft would like to submit XDR to the W3C for standardization so that other browsers can benefit from this technology. XDomainRequest (XDR) Table of Contents 1.0 Summary 2.0 Background: /Overview of how XDR allows cross site requests/ 3.0 API Documentation: /Lists the programming interface/methods/ properties/ 4.0 Security Model Flowchart: /Highlights the security checks that IE8 makes for an XDR Request./ 5.0 Sample Site and Script: /For developers wishing to create an XDR page./ 6.0 Developer Benefits of using XDR: /Covers XDR's strengths by demonstrating XDR's goals of security and simplicity./ 7.0 Developer Release Notes: /A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do
Re: Accessing Object Parameters from an Embedded SVG
Jeff Schiller wrote: I'm not well-versed on the history behind document.domain and how the web depends on it being writable. Can someone send me a pointer? I can understand not letting the embedded object get at the elements outside of the HTMLObjectElement, but this seems like a weird design flaw - the object parameters should be accessible to the embedded object, regardless of domain - that's their purpose. It would have been great if HTMLObjectElement had an accessible params NodeList readonly attribute :( That wouldn't really help. While you can get access to the object element using window.frameElement, you don't have access to do anything at all with it. Even if we added properties directly on HTMLObjectElement you would not be granted access to them. The proper fix here is IMHO to add something to the window object. So that you don't have to reach out into documents that are from a different domain. I would not rely on document.domain tricks. IMO document.domain is a hack and a much better solution to the problem it's trying to solve is postMessage. / Jonas
Re: Accessing Object Parameters from an Embedded SVG
Boris Zbarsky wrote (on 3/13/08 3:11 PM): It would have been great if HTMLObjectElement had an accessible params NodeList readonly attribute :( Yes, indeed. It's not too late to add that! Boris, do you mean that it's not too late to add that to Fx3? What about window.paramList? It's definitely too late to add anything to FF3. But I don't see that that matters in any way as far as working on a standardized solution goes. / Jonas
Re: IE Team's Proposal for Cross Site Requests
How do you define the Intranet, Internet, Restricted etc zones? Without correct definitions for these zones it seems possible to attack intranet servers by sending unsafe (such as POST or DELETE) requests to intranet servers from internet pages. I'd also recommend sending this to the web applications formats group since they have been working on a very similar security proposal. / Jonas Sunava Dutta wrote: Purpose XDR helps web developers to create secure mashups, replacing less secure or non-performant approaches, including SCRIPT SRC’ing content or IFRAME injection. Microsoft would like to submit XDR to the W3C for standardization so that other browsers can benefit from this technology. XDomainRequest (XDR) Table of Contents 1.0 Summary 2.0 Background: /Overview of how XDR allows cross site requests/ 3.0 API Documentation: /Lists the programming interface/methods/properties/ 4.0 Security Model Flowchart: /Highlights the security checks that IE8 makes for an XDR Request./ 5.0 Sample Site and Script: /For developers wishing to create an XDR page./ 6.0 Developer Benefits of using XDR: /Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity./ 7.0 Developer Release Notes: /A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do./ 1.0 Summary /With* Cross Domain Request* *(XDR)* developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1 http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html, 2 https://bugzilla.mozilla.org/show_bug.cgi?id=389508), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered http://blog.monstuff.com/archives/000302.html (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative./// 2.0 Background Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser. Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server. In IE8 web pages can simply make a cross domain data request within the browser using the new /XDomainRequest/ object instead of a server-to-server requests. Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a /xdomainrequest /object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a /XDomainRequest: 1 /header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true. For example, a server’s asp page includes the following response header: Response.AppendHeader(XDomainRequestAllowed,1); *Security note: *Cross domain requests are anonymous to protect user data, which means that servers cannot easily find out who is requesting data. As a result, you only want to request and respond with cross domain data that is not sensitive or personally identifiable. 3.0 API Documentation * * *Methods* Once you create a xdomainrequest object, you can use the /open()/ method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the /send()/ method to send a data string to the server for processing if needed. For example: // 1. Create
Re: [xmlhttprequest] getResponseHeader() for invalid header
Anne van Kesteren wrote: On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote: Currently getResponseHeader() returns the empty string for invalid header names. Would people object if I changed that to returning null instead (basically making it equivalent to headers not part of the response)? Thanks. What do current implementations do for these cases? I think three out of four return null for a non-existent header (IE being the exception, iirc). Firefox and an internal version of Opera also return null for invalid headers. (Although for Firefox it seems to differ on based on whether the request has happened already or something...) I think firefox throws if we haven't received the full response head yet. Which I sort of think makes sense since we don't know yet what the correct return value is. / Jonas
Re: XHR setRequestHeader(connection, close) is bogusly rejected
Kris Zyp wrote: However, there are web apps in existence (e.g., Gmail) that set the connection: close header to inform the user-agent that the HTTP transaction is going to take a long time. (This is also informative for the server.) This allows a user-agent to not count this connection against the RFC 2616 recommended maximum of 2 persistent connections per host. As far as I can tell, Firefox is the only browser that regards connection: close as an indication that the connection should not be counted against the connection limit What gives you that idea? I'm not actually sure since I don't know the inner workings of the network code, but I have never heard of such behavior. And in any case Firefox 3 does not even let you set the Connection header using XHR. / Jonas
Re: XHR setRequestHeader(connection, close) is bogusly rejected
Morgan L wrote: Hi, I'm writing about what appears to be an error in the XHR TR. In section 2 of http://www.w3.org/TR/XMLHttpRequest/, it says that setRequestHeader should reject the connection header. However, there are web apps in existence (e.g., Gmail) that set the connection: close header to inform the user-agent that the HTTP transaction is going to take a long time. (This is also informative for the server.) This allows a user-agent to not count this connection against the RFC 2616 recommended maximum of 2 persistent connections per host. So, it seems to me that the arguments setRequestHeader(connection, close) should be allowed. More details in this WebKit bug: http://bugs.webkit.org/show_bug.cgi?id=17682 It looks like recent versions of WebKit and Gecko block the connection request header per this TR. However, Firefox 2 does not. We do block, but not because of this TR. IIRC there are security issues with other values for connection, though I don't specifically remember what they are. However setting something like connection: keep-alive when the browser is not expecting that could have bad effects on other connections to that server. / Jonas
Re: Extra Connection Support Proposal
Kris Zyp wrote: you click on a link, does the link get followed? That is the same sort of scenario, isn't it? At least firefox will abort any existing downloads for the current page when the user clicks a link. But if you're downloading these images in another tab you might have this problem yeah. Though if it's simply multiple images the new page will likely get squeezed in between two of the image downloads. And there is an important distinction between images being downloaded that consume connections and a long-lived response that consume a connection. With normal responses, two connection usually provides a means for relatively continuous utilization of resources. Most of the time two connections provide enough requests that the usually the server is processing a request, or a response is downloading. Either way, something is being done, and it is quite reasonable for further requests to be queued, since the server/connection is working to finish the response as fast as possible within it's capability. On the otherhand, when a long-lived response is paused indefinitely until a the server has a message to be sent, there is nothing being done. Nothing is being downloaded, and the server isn't working on anything, and requests can be queued indefinitely even though nothing is happening. Yup, it seems like people agree with this. It's just the proposal to put it as a feature on XHR that seems to be disliked by a few people, me included. Doing this on an HTTP level seems like the right solution to me. Though i'm not sure what working group would then be appropriate for standardizing it... / Jonas
Re: Security-sensitive headers
Collin Jackson wrote: On Tue, Feb 19, 2008 at 1:10 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: specification we'd have to chose a header name that starts with Proxy-. There have been many other proposals for new security-related HTTP headers (e.g. content restrictions) so it would be nice to solve this issue in general. Comments like this do encourage me to introduce Sec- so we don't get a whole bunch of fake Proxy- headers. (Note that not all clients blaclist everything Proxy- yet.) Please make sure to block setting the Access-Control-Origin header, or rename it to have a restricted prefix. If a page could use XMLHttpRequest to spoof this header for same-origin requests, it could use DNS rebinding to spoof this header in a request to an IP address of the attacker's choosing. If the target server was validating the Access-Control-Origin header but not the Host header, the server would think the request came from the wrong origin. Currently released browsers are always going to be able to send this header. If that is a big security problem I suggest you bring that up on the WAF mailing list and detail your concern. / Jonas
Re: Extra Connection Support Proposal
Stewart Brodie wrote: Kris Zyp [EMAIL PROTECTED] wrote: We are still faced with the fundamental problem that if a browser that observes the two connection limit and two long-lived connections are currently open and the user does something that triggers another request (such as opening another tab), the browser is stuck and essentially hangs waiting for a connection to become available. This is a serious usability issue. Is there something that I need to do to improve my proposal, so can effectively tackle this issue, and provide a means for authors to inform the user agents when a response is long-lived? The problem has always existed, though. For example, if you're downloading a page with very large images on it (or perhaps multipart/x-mixed-replace feeds from a webcam) and whilst the browser is tied up downloading them all, you click on a link, does the link get followed? That is the same sort of scenario, isn't it? At least firefox will abort any existing downloads for the current page when the user clicks a link. But if you're downloading these images in another tab you might have this problem yeah. Though if it's simply multiple images the new page will likely get squeezed in between two of the image downloads. / Jonas
Re: [selectors-api]
Anne van Kesteren wrote: On Tue, 19 Feb 2008 10:43:14 +0100, Boris Zbarsky [EMAIL PROTECTED] wrote: The only solution I'm seeing so far to a hanging NSResolver is terminating that script at some point. Is that what you're doing for treewalker node filters? Yes. I'm not sure why we should specifically define what to do with a hanging NSResolver case. I think it should be treated identically to a hanging script. (Ideally they run forever with the UI still being usable.) Agreed. I think it's outside the scope of the spec to try to deal with this. I think the text about behaving in the face of a hostile NSResolver should be informative rather than normative (not sure if it already is), and possibly live in a security considerations section. / Jonas
Re: [selectors-api]
Lachlan Hunt wrote: Boris Zbarsky wrote: Anne van Kesteren wrote: To ensure that naïve implementors don't overlook the potential issue here. An implementation of NSResolver can be provided by the script author as the specification explains and the script author can do all kinds of weird things that don't match a conforming implementation of NSResolver (such as mutating the DOM tree). Is a conforming querySelector implementation allowed to throw an exception when this happens? No. It is only allowed to throw an exception when the text says so. In that case, can you please describe what is a conforming behavior for a querySelector (or querySelectorAll) implementation if: 1) It needs to call the NSResolver on every match attempt 2) The NSResolver mutates the DOM on every match attempt That would seem to be a very inefficient implementation, though I suppose the spec should deal with the possibility in one way or another. If you're going to require the implementation to deal with NSResolvers which do random stuff but put too many constraints on what it's allowed to do to deal with them (as you are), you make an implementation impossible. Now maybe you're actually requiring that the number of calls to the NSResolver for any given selector and initial DOM tree is bounded in the face of all possible mutations by the NSResolver and that hence the DOM will at some point stabilize and it will be possible to return the things the spec requires be returned. But if that's a constraint you want to place on implementations, you should probably spell it out clearly. Note that in Gecko I suspect the NSResolver would only be called during the parsing of the selector, so we could in fact return the things the spec requires... on the post-mutation DOM, not the pre-mutation one. It's not clear to me from the spec whether this would be conformant. It's not clear to me what the spec should say to resolve this issue. Do you have any suggestions? For what it's worth, the DOM-XPath spec more or less dictates that the NSResolver is only used during parsing of the expression. I think this is a very acceptable requirement given how much hassle arises if the implementation were to use the NSResolver were used while executing the expression. The exact same applies to the selectors API IMHO. I.e. I don't see a need to allow an implementation like the one described by Boris. / Jonas
Re: Pipelining Control Proposal
An important difference is that most other features non-uniform across browser, not across users. A web developer can test the browsers they are interested in supporting. It's much harder for the developer to test the various user environments that are going to affect pipelining. Don't get me wrong, I'd love pipelining as much as everyone else. I'm just not convinced that adding it through XMLHttpRequest is a solution that will help. Another worry I have with the proposal is that I think XMLHttpRequest would be the wrong place to implement this. It's really a HTTP feature that should be implemented unrelated to XMLHttpRequest so that the rest of the browser can make use of it. Once we figure out a way to do it safely that is. / Jonas Kris Zyp wrote: Just about every feature available to web developers is non-uniformly available! Pipelining is vastly more broadly available than just about anything we have available to us. And arguments based on the unreliability of pipelining have still lacked any hard evidence. Dropping a proposal shouldn't be based on FUD. The bottom line is even if some proxies don't handle pipelining, application authors should have the choice. Authors are aware of the risks and can make informed decisions when other browser features aren't uniformly available, and they should have the choice in this matter as well. We shouldn't just assume that all developers are stupid and just throw are hands up in despair that we can never have pipelining. That won't lead to progress. This is our best opportunity to have an inroad to pipelining, via consenting authors. Kris - Original Message - From: Jonas Sicking [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: public-webapi@w3.org; Mark Baker [EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 11:26 AM Subject: Re: Pipelining Control Proposal I would be very worried about implementing this feature in a browser since it runs a very big risk of creating websites that only work for some users. I.e. for users with a direct connection to the server the website would work fine, but for users sitting behind a proxy or a firewall the site would break. I doubt we can expect web authors to appropriately write fallback code when in their testing pipelineing will work fine. / Jonas Kris Zyp wrote: Pipelining Control HTTP Pipelining is when more than one outstanding request is sent over a single TCP connection, and it was introduced in HTTP 1.1. This proposal defines that XHR objects should be able to control whether or not they are pipelined. A pipeline property would be added to the XHR object. If pipeline property is set to true, when send is called, the XHR request SHOULD be pipelined over one of the currently active connection, even if all connections to the target server are currently waiting for a response. That is, the request should be pipelined if necessary to send it immediately. If there is an available connection is alive, but no responses are waiting, the request should be sent on this connection (just as a non-pipelined request would be). If the pipeline property is set to false, the XHR request SHOULD NOT be pipelined even if the user agent supports and would otherwise pipeline the request. The pipeline property may also be set to another XHR object with an open connection, in which case the request should be pipelined on that specific TCP connection. For example: var xhr1 = new XMLHttpRequest(); xhr1.open(GET,/resource1,true); xhr1.send(null); var xhr2 = new XMLHttpRequest(); xhr2.open(GET,/resource2,true); xhr2.pipeline = xhr1; xhr2.send(null); In this example, both requests should be sent over the same TCP connection. The GET for resource1 should be sent and the GET for resource2 should be pipelined behind the first request on the same connection. If a connection has been marked as an extra connection with the extraConnection property on the XHR object (see the extra connection proposal), that connection should not be used for pipelined requests unless another XHR request explicitly specifies that connection, in which case that XHR request SHOULD be pipelined on that connection. (This is because the extra connection request is generally to be used for long-lived responses that are kept open for server-sent messages. Requests that are sent behind such a request may never receive a response, which should not be the default behavior, but may be explicitly chosen to achieve full asynchronous duplex communication on a single TCP connection, a highly valuable capability channels with server-sent messages.) If a network error occurs while servicing a request, any pipelined requests that are queued behind the first request SHOULD NOT automatically be retried by the user agent. A network error in response to the first request should cause an error condition for both the first XHR object and all subsequent pipelined XHR objects per normal XHR behavior
Re: [selectors-api] Selectors API comments: section 2
Anne van Kesteren wrote: On Fri, 15 Feb 2008 19:36:21 +0100, Jonas Sicking [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: I have added the following text to the spec: If the user agent also supports some level of CSS, the implementation must support the same set of selectors that are supported by the CSS implementation. This doesn't really make it clear if that is 1 or 2 above. In both cases the same set of selectors are supported, but for 2 the selectors-api implementation is allowed to implement additional selectors. If one is a superset, how are they still the _same_ set? The text above only says that the API impl has to support the same set as the CSS impl. It doesn't say that the CSS impl has to support the same set as the API impl. I.e. I see nothing that prohibits the API impl from supporting additional selectors. / Jonas
Re: IE Team's Feedback on the XHR Draft
Hi Sunava, Thanks for your feedback. I had a couple of additional comments on top of the ones Anne had. On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta [EMAIL PROTECTED] wrote: o This spec is very different from existing HTML/CSS/DOM spec where the functionality/API specification is the focus. This spec talks about interface specification as well as a lot of details that appear to be internal implementation issues that cannot be verified by Web developers. I don't think that's true, actually. In fact, the specification leaves implementation details up to the implementation. It says so in the conformance criteria. So one thing to note is that the implementation doesn't need to keep exactly the same flags, references, states etc as the ones talked about in the spec. As long as it to any user behaves as if it did. So for example in the mozilla implementation we don't have the send() flag, instead we have one additional main state for the object. I.e. we have 6 states, including OPENED_BUT_NOT_SENT and OPENED_BUT_SENT. To the outside world this is not noticeable since the getter for the readyState property returns 1 for both those states. Maybe we need to point out at the top of the specification something to the effect of the implemenatation doesn't need to use the same algorithms or use the same states as the ones described in this specification. As long as it to any user of the interface yields the same results as if it had. Having internal implementation recommendation for UA's is nice, however we can improve the readability by calling out implementation detail sections or having a separate section for this detail . What we've love is to have the spec clearly state what is external API specification, and what is internal implementation details. This way a web developer can read this without reading the whole spec and take away the key points. I think everything that is not important is not there. So I don't really see the issue. I think the request here is to use language like if the opened method has been called, but the send method has not then do X rather than if we're in the OPENED state with the send() flag set to false then do X. Is that correct? The problem with that is that it's hard to get that unambigious and correct. For example the first wording above is wrong since open might have been called, but abort had later been called, and so we should behave as if open had not been called. Or I might just be misunderstanding you :) o Is this included due to security concerns? § Scripts in the resulting document tree will not be executed, resources referenced will not be loaded and no associated XSLT will be applied. It's included to get consistent behavior. Right, I don't think any current implementation applies XSLT stylesheets. Additionally, loading resources, such as images and stylesheets, pointed to by the document would largely be a waste of network traffic as they won't be displayed anyway. We've had cases where people load XSLT stylesheets using XHR and then use javascript to dynamically apply these stylesheets to documents. XSLT stylesheets can contain markup like: xsl:for-each select=images/image html:img src=/static/images/[EMAIL PROTECTED] /xsl:for-each In this case it would be clearly undesirable if the loading the XSLT stylesheet using XHR would attempt to load the resource /static/image/[EMAIL PROTECTED] from the server. Hope that helps? Actually, the spec should probably also say that stylesheets should not be applied. This is needed since the stylesheet might be inline and thus not stopped by the don't load resources rule. Anne, should that be added to the draft? / Jonas
Re: IE Team's Feedback on the XHR Draft
Doug Schepers wrote: Moreover, this is, in fact, what this WG was chartered to do regarding XHR: This deliverable should begin by documenting the existing XMLHttpRequest interface. The question becomes, is IE's implementation to be considered canonical, or is it up to interpretation vis a vis later implementations (FF, Opera, Safari, et al)? I remember that we started the XHR spec with this goal. However it pretty quickly became clear that we couldn't archive a useful subset of functionality that was compatible between all existing implementations. I think in all cases we've tried to be as compatible with implementations as we could, but in cases where we couldn't we've had to compromise. Pursuant to that, is there a way to document the existing behavior such that it does not make existing implementation retroactively non-conforming? Or that does not affect existing content? I don't know whether or not the existing specification meets these criteria, but I think that would be the best path forward. I don't think doing that would be very useful as a spec. It would basically just be a brief tutorial of the various functions and their arguments. Something that there are plenty of on the web already. / Jonas
Re: [Bindings] stringify
Anne van Kesteren wrote: Maybe the draft already says something about this, but I couldn't find it. I think it would be good if there was a way in the IDL to say what an object stringifies to. The Window object becomes [object Window] and Location stringifies to its href attribute value. The tricky part here is objects implementing multiple interfaces, such as Document and DocumentSelector, but in those cases the specification editors should probably ensure there are no strange things. I don't think the IDL is the right place to put this. Instead it is information that should be associated with the objects implemented with the interface. One good reason is the one you bring up, that an object can implement multiple interfaces. Another is that a interface, such as EventTarget, might be implemented by multiple objects with different stringifications. / Jonas
Re: [XHR] send doesn’t explain what to do when method is GET
Maciej Stachowiak wrote: On Dec 14, 2007, at 4:11 PM, Jonas Sicking wrote: Julian Reschke wrote: Jonas Sicking wrote: Does any currently released browse include the body when doing an XHR GET request? If a big majority of them currently drop the body, then it seems like it would help interoperability if the spec explicitly stated that the body should be dropped. Disagreed. Please do not try to standardize HTTP APIs that profile what HTTP allows. XHR already disallows a lot of things that HTTP allows. Setting certain headers, cross site requests, etc. Why is this different? Besides that, Björn already reported that both IE7 and FF happily pass the body, as they should (IMHO). My reading of Björns email was that they did not drop it for HEAD, OPTIONS and EXAMPLE did not drop the entity body. In my testing IE, Firefox and Opera all dropped the entity body of GET requests. Did you try Safari (or can you post the test case so I can try it?) I did not try safari. You can try it here: http://people.mozilla.com/~sicking/xhr_body.html / Jonas
Re: [XHR] send doesn’t explain what to do when method is GET
Anne van Kesteren wrote: On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: 3) The spec as written doesn't state nothing, it appears to clearly require sending an entity body and does not allow ignoring the body or throwing an exception regardless of what is allowed per RFC. So some change is needed, one way or another. Ok. How about we add a step 5 of the send() algorithm that states that additional requirements in RFC 2616 are also to be taken into account. That should effectively defer the issue to RFC 2616. Does any currently released browse include the body when doing an XHR GET request? If a big majority of them currently drop the body, then it seems like it would help interoperability if the spec explicitly stated that the body should be dropped. IMHO this wouldn't be going against RFC 2616 as it's the application, not the network layer, that drops the body. / Jonas
Re: [XHR] send doesn’t explain what to do when method is GET
Stewart Brodie wrote: Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: 3) The spec as written doesn't state nothing, it appears to clearly require sending an entity body and does not allow ignoring the body or throwing an exception regardless of what is allowed per RFC. So some change is needed, one way or another. Ok. How about we add a step 5 of the send() algorithm that states that additional requirements in RFC 2616 are also to be taken into account. That should effectively defer the issue to RFC 2616. Does any currently released browse include the body when doing an XHR GET request? If a big majority of them currently drop the body, then it seems like it would help interoperability if the spec explicitly stated that the body should be dropped. IMHO this wouldn't be going against RFC 2616 as it's the application, not the network layer, that drops the body. Under no circumstances will my code permit an entity body to be sent as part of a request for an object that is going to be requested via GET or HEAD. It's just asking for trouble. It also will not permit related headers to be set (Content-Length, Transfer-Encoding et al will be dropped) Actually, once we're supporting cross site GET requests, I think we there should definitely mention that the entity body of GET (and probably HEAD) requests are dropped. Otherwise there is some risk that there are servers out there that will do dangerous things when receiving GET requests with an entity body, such as treat it as a POST. This seems like just one more argument for explicitly stating that the entity body for GET should be dropped at an XHR level. / Jonas
Re: [XHR] send doesn’t explain what to do when method is GET
Mark Baker wrote: On 12/14/07, Jonas Sicking [EMAIL PROTECTED] wrote: Actually, once we're supporting cross site GET requests, I think we there should definitely mention that the entity body of GET (and probably HEAD) requests are dropped. Otherwise there is some risk that there are servers out there that will do dangerous things when receiving GET requests with an entity body, such as treat it as a POST. Nah. And if a server does that, whomever installed it only has themselves to blame. This seems like just one more argument for explicitly stating that the entity body for GET should be dropped at an XHR level. No. Look, if you don't want to have to take on the extra work of fully supporting HTTP (for what is, admittedly, currently a fringe case), fine, don't. Just please don't ask that we tell those who are willing to do so, that they can't. Given that none of the current browsers support this today, I'm not sure who we would help by saying that this is non-conformant behavior. / Jonas
Re: [Bindings] extended attribute for callback function interfaces?
L. David Baron wrote: There are a number of interfaces, used as callbacks, like EventListener [1], NodeFilter [2], and UserDataHandler [3], and XPathNSEventResolver [4] where an interface has a single method and is intended to be implemented by the DOM user as a callback. In ECMAScript bindings, the implementation typically accepts a raw function for such cases, in addition to (or rather than, in some implementations, perhaps?) an object with a named property for the function. Should there be an extended attribute to indicate such interfaces? (I'd note that Mozilla's IDL has such an extended attribute, [function].) Yes, I definitely think this is needed. Current specifications use English descriptions in the ECMAScript bindings to accomplish that behavior to be specified, it would be much more easily detected and precisely described if we could use an extended attribute for this. / Jonas
Re: Feedback from the IE Team: Web API XHR Draft
Mike Wilson wrote: But it turned out in the course of developing the spec that there were enough individually small differences to make such an excercise fruitless. Considering that IE invented XHR (apart from the object naming), couldn't the first version of the spec just describe the existing IE behaviour in detail? That would match the previous wg intention and certainly make things easy for the IE team and their backwards compatibility. That would mean the first step in the following plan: 1) Describe original XHR implementation(s) in detail. 2) Iron out kinks and upgrade to new DOM/BOM types without adding functionality. 3) Add functionality (currently some mentioned as future or Not in this Specification). I would strongly argue that w3c is in the business of creating the best specification we can based on technical grounds, not to thank individual vendors for their great job of inventing new technologies. What we should do is build the best spec we can to move the web forward. I'd be very interested to hear arguments for changes to the spec to do that. / Jonas
Re: XHR: definition of same-origin
Boris Zbarsky wrote: Anne van Kesteren wrote: I think HTML5 needs to define this as my understanding is that document.domain is also relevant in deciding whether or not a request is same-origin. Actually, I don't think it is. I know IE and Gecko ignore document.domain for the existing same-origin checks... Gecko used to take it into account, but of course that broke sites given that IE ignores it. Taking document.domain into account when doing same-origin network activity would infact be unsafe. Otherwise content at people.example.edu would be able to load data from example.edu which might not be safe. In fact, in order for people.example.edu to talk to example.edu, *both* sites must explicitly have set document.domain to example.edu. This is of course not something that can happen before a network request, as the requested site has no way of setting document.domain. Not sure how things originally worked when document.domain was implemented many moons ago, but at this point all vendors have fixed this issue. / Jonas
Re: [xhr2] cross site non-GET requests and redirects
Anne van Kesteren wrote: On Mon, 06 Aug 2007 23:39:28 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Given domain A and B I wonder if it's a problem if when a request is done from A, B can feed information back to A (through the URL; http://domain-a.org/?data=data) without any sort of access check being done anywhere. Yeah, I've been thinking about this scenario too. I think I agree with you actually, especially given that I don't see any good usecases for not doing the check in this scenario. Agree? I was just wondering :-) In any case, I could easily solve this in the specification by having a has been non same-origin flag which is set to true the moment you make a non same-origin request or you are redirected to a non-same origin location. Based on the value of that flag you would then decide to do an access check. Sounds reasonable? (Besides of course the already in place algorithms for a non-GET request to a same-origin server which redirects to a non same-origin server.) Yes, this sounds good. / Jonas
Re: [xhr2] cross site non-GET requests and redirects
Anne van Kesteren wrote: By the way, a request to a same-origin redirect that redirects to a non same-origin resource should also work I suppose? Or is there some reason you need to know in advance you're going to make a non same-origin request? For GET requests I don't see a reason to not allow redirects from same-origin to another server. For POST and other methods it is a bit more complicated since you at the point of the redirect have to switch to sending out a GET requests first to make sure that the POST is safe. At least in mozilla we can't stall the redirect while waiting for the GET to finish. It is probably possible though to cancel the initial request, fire the GET request, and then perform the redirect. Would be good to get other implementors input on this. Also, what happens for same-origin which redirects to non same-origin which redirects to same-origin again. Do you perform an access check? In the implementation I've written, the decision weather to check access control headers is done by comparing the final uri with the requesting uri. So if you're redirected back to the original server no access-control check is done. I'd be all ears if someone think we should do checks as soon as a request has passed another domain at some point. / Jonas
Re: [XHR2] overrideMimeType
Alexey Proskuryakov wrote: On 7/30/07 12:21 AM, Jonas Sicking [EMAIL PROTECTED] wrote: If XHR2 offers responseBody with a raw byte array of some kind, it will be required for implementations to keep the raw bytes around anyway. Yep. Though it still seems weird to me that responseText would change when .overrideMimeType is changed. How do you guys deal with this situation? Currently, we only honor MIME type (not charset) change after the response bytes start to arrive, and only if responseXML hasn't been accessed yet. So setting overrideMimeType does different things before and after the load starts? That doesn't seem very ideal either. / Jonas
Re: [XHR2] overrideMimeType
Maciej Stachowiak wrote: On Jul 27, 2007, at 12:09 PM, Jonas Sicking wrote: Anne van Kesteren wrote: I've been looking at overrideMimeType implementations in Gecko and WebKit and it seems like they differ a bit. In Gecko it has to be invoked before send(), but in WebKit it would work if you invoke it just before getting responseXML or responseText. Neither implementation seems to do any input checks. If you have any opinion on how it should be specified I suppose now would be the time to air your thoughts. Of course I prefer the mozilla way :) It does seem fairly complicated to allow it to be set after the download is finished though. You do have the stream stored in .reponseBody, but at that point all encoding information has been lost. For HTML parsing (which I hope the spec will support in the future) there are a pile of rules used to guess the encoding, all of which would be useful to use, but can't be used if all you have access to is the unencoded responseBody. Why would the encoding information be lost? The only sources of encoding info are the responseText itself and http headers, both of which the XMLHttpResponse needs to provide anyway. ResponseText is not the raw byte stream gotten off the wire, it is already decoded into utf16 using whatever algorithm we define for determining the encoding. HTML decoding is a lot more complicated since you have to first guess an encoding, then start to parse the document, but if you find a meta http-equiv=Content-Type content=text/html; charset=? Where charset is different from what you guessed, you have to restart from the beginning using the charset defined in the meta tag. Yes, it would definitely be possible for the implementation to keep around the raw byte stream and either lazily decode responseText, or keep both the utf16 responseText and the raw byte stream around. It is a bit quirky behavior though since setting overrideMimeType could then change the encoding and therefor both responseXML and responseText. / Joans
Re: [XHR2] text/html and responseXML
Maciej Stachowiak wrote: On Jul 28, 2007, at 4:04 AM, Anne van Kesteren wrote: Jonas already mentioned it in another e-mail and this feature was indeed planned (by me 8-)) for XMLHttpRequest level 2. responseText already follows text/html rules for encoding detection etc. but for parsing we probably need to state that it needs to run with support for scripting disabled which affects how noscript is parsed etc. I'm wondering if we should do it like that or have scripts not run and parse noscript as if scripting was enabled. (I'm not sure whether HTML 5 has an option for the latter, but that's for instance how html5lib currently works.) Any opinions on this? Anything else I should pay attention too when adding this feature? I would guess a popular use would be to grab HTML fragments and insert them into the current document, in which case it would be desirable to parse as if noscript was not disabled. I'm also not sure that scripting needs to be disabled, at least in the non-cross-domain case. I could imagine interesting uses for either. The author always has the option of not including noscript elements in their response, so I think the usecase is still supported. I'm a little bit worried that if we enable scripts for XHR (they are currently disabled in firefox) that sites would break. Though chances are probably pretty small. However if scripts are enabled we need to define exactly in which context they execute. Should they have their own 'window'? If not 'window.document' would not refer to their own document. / Jonas
Re: [XHR2] overrideMimeType
Anne van Kesteren wrote: On Fri, 27 Jul 2007 21:09:37 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: It does seem fairly complicated to allow it to be set after the download is finished though. You do have the stream stored in .reponse[Text], but at that point all encoding information has been lost. For HTML parsing (which I hope the spec will support in the future) there are a pile of rules used to guess the encoding, all of which would be useful to use, but can't be used if all you have access to is the unencoded responseBody. It would make sense for consistency with the other methods if the method throws if you try to invoke it after send() has been invoked. Can that still be changed in implementations? And maybe also throw a SYNTAX_ERR if it does not match the MIME type syntax (also for consistency). For mozilla this would be an easy change since setting it after data starts coming in is a no-op. So we don't really risk breaking anyone who wasn't broken already. Sounds like it would be a bigger change for apple. / Jonas
Re: [XHR2] text/html and responseXML
Anne van Kesteren wrote: Jonas already mentioned it in another e-mail and this feature was indeed planned (by me 8-)) for XMLHttpRequest level 2. responseText already follows text/html rules for encoding detection etc. but for parsing we probably need to state that it needs to run with support for scripting disabled which affects how noscript is parsed etc. I'm wondering if we should do it like that or have scripts not run and parse noscript as if scripting was enabled. (I'm not sure whether HTML 5 has an option for the latter, but that's for instance how html5lib currently works.) Any opinions on this? Anything else I should pay attention too when adding this feature? I can't say I feel very strongly about it. But it seems more logical to me to parse the contents of noscript as if scripts were disabled. Other things that should be disabled is loading stylesheets (which can affect .getComputerStyle and XBL bindings), onclick-like attributes and loading of plugins. This is in reality an issue even in XHR 1 due to XHTML. / Jonas
Re: [xhr2] cross site non-GET requests and redirects
Anne van Kesteren wrote: It seems nicer however to not restrict it to XMLHttpRequest and define the entire retrieval algorithm in the access-control specification including how it works for other methods and in face of redirects. I agree. I don't really want to hold up the [ac] spec though. At the same time we're shipping experimental support in the next firefox alpha release so the sooner we can get this all defined the better. By the way, a request to a same-origin redirect that redirects to a non same-origin resource should also work I suppose? Or is there some reason you need to know in advance you're going to make a non same-origin request? For GET requests I don't see a reason to not allow redirects from same-origin to another server. For POST and other methods it is a bit more complicated since you at the point of the redirect have to switch to sending out a GET requests first to make sure that the POST is safe. At least in mozilla we can't stall the redirect while waiting for the GET to finish. It is probably possible though to cancel the initial request, fire the GET request, and then perform the redirect. Would be good to get other implementors input on this. / Jonas
Re: [xhr] cross site proposal headers
Anne van Kesteren wrote: On Mon, 23 Jul 2007 10:35:27 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: A couple of questions regarding the cross-site XHR proposal: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest cross-site requests should alway have the headers set through setRequestHeader removed. This includes requests done after a redirect to a different server. Why prevent a user from setting the Content-Access-Control header? That is generally a response header and I'd expect servers to ignore it. If requests with arbitrary headers set can harm a server they are already vulnerable. Is it really wise to restrict this? I'm arguing for allowing the header to be set, as no server has any reason to pay attention to it. What is the purpose of the Referer-Root header? Why can't sites rely on the Referer header? Isn't Referer disabled by some third-party software now and then? Such as antivirus software? Another reason is probably that Referer-Root contains the exact format needed for the access check. We could use that in the access-control document probably. This seems like a loosing battle that I don't see a reason to fight. If the user (by installing software or through corporate policies) disables the Referer header, why should we try to circumvent them? That seems just likely to piss them off and then add Referer-Root to their blocking list. If the sites want to use the Referer header and it has been blocked the site can simply deny the request. Non-idea for the end-user, but by their own choice. / Jonas
Re: [xhr] proxy-connection header
Julian Reschke wrote: Jonas Sicking wrote: The XHR spec currently allows users to set the Proxy-Connection header using setRequestHeader method. I couldn't find a spec for it other than some discussions here: ... As far as I can tell, the spec doesn't even mention the header. Are you saying the spec should disallow setting a header that isn't even registered (http://www.iana.org/assignments/message-headers/)? Yes, if it's a security problem not to. IMHO that should be the determining factor. Actually, I'm wondering if we should disallow any header starting with Proxy-. For example Proxy-Authorization header looks scary to me. / Jonas
[xhr] cross site proposal headers
Hi All, A couple of questions regarding the cross-site XHR proposal: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest cross-site requests should alway have the headers set through setRequestHeader removed. This includes requests done after a redirect to a different server. Why prevent a user from setting the Content-Access-Control header? That is generally a response header and I'd expect servers to ignore it. What is the purpose of the Referer-Root header? Why can't sites rely on the Referer header? / Jonas
Re: [xhr] cross site proposal headers
Jonas Sicking wrote: Hi All, A couple of questions regarding the cross-site XHR proposal: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest cross-site requests should alway have the headers set through setRequestHeader removed. This includes requests done after a redirect to a different server. Oh, I was going to add to this. I plan on allowing Accept and Accept-Language to be set even for cross-site requests. Are there other headers that people think would be useful and safe to allow? / Jonas
Re: [xhr] cross site proposal headers
Julian Reschke wrote: Jonas Sicking wrote: Jonas Sicking wrote: Hi All, A couple of questions regarding the cross-site XHR proposal: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest cross-site requests should alway have the headers set through setRequestHeader removed. This includes requests done after a redirect to a different server. Oh, I was going to add to this. I plan on allowing Accept and Accept-Language to be set even for cross-site requests. Are there other headers that people think would be useful and safe to allow? Could you point me to the rational for forbidding setting headers in the first place? HTTP headers are an important extension point (see for example APP Slug), but disallowing then completely seems to be a very drastic measure. The only thing documented is the wiki.mozilla.org page linked above. The rationale is simply that allowing any random header (except for the small black-list in the spec) to be set in a HTTP GET request to any server is a big expansion of what browsers currently allow. Remember that these servers could be servers behind a firewall or servers where the user is logged in or has cookies set. Rather than questioning why we're forbidding it, we asked, how would we know it's safe to allow it? And since we didn't know we opted for the safer path. / Jonas
[xhr2] cross site non-GET requests and redirects
Hi All, I'm currently working on implementing cross-site XMLHttpRequest as detailed in this draft: http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 However I'm a little bit worried about two things regarding non-GET requests. First of all I don't like that POST requests can be made unchecked to any url. I do realize that this seems possible already using plain/text encoded forms, but this is possibly something that browsers will need to change. Second, I'm a little bit worried about the algorithm used to for non-GET (non-POST in the current draft) in connection with redirects. From my understanding the following is a valid scenario: 1. Web page on server A makes a DELETE request to server B 2. XHR implementation sends a GET request to server B 3. Server B redirects to server C 4. Server C sends reply that approves the request using appropriate headers and an Allow: DELETE header 5. XHR implementation sends DELETE request to server B 6. Server B deletes file on requested uri. What worries me is that in step 5 the DELETE request is sent to server B even though server B has never explicitly allowed that. Granted, since the redirect chain for the DELETE request is not the same for the initial GET request as for the DELETE request, the returned result will not be accessible to the web page, but that hardly matters as the damage is already done. The only thing server B has done is to redirect to server C. This could be done without any knowledge of XHR or the cross-site spec. I propose we instead specify that the DELETE request should be done to the final uri of the redirects in the GET request. And if the DELETE request produces any redirects then those must not be honored. Do other people have an opinion? In general it feels to me like redirects and non-GET requests cross site is a rare edge-case and not something that is particularly important. So we might as well do the safe thing. I could even see disallowing redirects entirely, even for the initial GET request. Best Regards, Jonas Sicking
Re: Selectors API Method Names
Maciej Stachowiak wrote: On Jul 2, 2007, at 3:50 PM, Charles McCathieNevile wrote: On Mon, 02 Jul 2007 20:17:40 +0200, Doug Schepers [EMAIL PROTECTED] wrote: Hi- Maciej Stachowiak wrote: I don't have a strong objection either way, but I think the case against Lachy's original names (selectElement, etc) has been laid out more clearly than the case against cssQuery. I think selectorQuery (as suggested in follow-ups) would also be ok. I think that the chief problem with cssQuery*() for me is that it is rather confusing. Such a name would indicate functionality related to CSS (that is, something presentational or style-oriented), rather than the accident of a historical relationship. It totally fails the criteria of being functionally descriptive, which selectElement() meets (other merits notwithstanding); this is a point on which I think we can build consensus and compromise (and hopefully a speedy resolution). Similarly, with selectorQuery() (which is better), you lose the verby action word of the existing naming convention (getAByB); selectorQuery sounds more like a property than a method. Frankly, I'm not a fan of any of the present crop of names, but in the interest of keeping forward momentum, I least object to what we currently have, selectElement*(). Thank you Doug for so eloquently stating the details of my objection. As it happens, I agree with you that I would rather move forward with the consensus on selectElement*, if we establish that, than keep chasing round for new names. I really think the confusability of this with selectNodes/selectSingleNode is a significant problem. matchSelector or querySelector doesn't have this problem, and also doesn't have the problems of cssQuery (slightly inaccurate mention of css, doesn't sound like a verb phrase). But I won't stand in the way of an editorial decision on this one. Same feelings here. Except that IMHO matchSelector sounds like something that would return a bool indicating if an element matches the given selector. So querySelector is the one I like the most so far (except for getElementsBySelector, but I'm not even going to suggest that one :) ) / Jonas
Re: requirements for a network spec
[EMAIL PROTECTED] wrote: Hi folks, we need to figure out what is really needed. A big requirement is security. It must not be possible to connect to an arbitrary port on the server and send anything, unless the server has explicitly stated that it allows so using some sort of white-listing mechanism. / Jonas
