Re: [XHR][XHR2] HTTP redirects / XHR Version detection
On Sun, 31 Jan 2010 00:45:17 +0100, David Bruant dbru...@ucsd.edu wrote: Le 30/01/2010 04:41, Anne van Kesteren a écrit : The idea is actually that a redirect does not involve a state transition. I have suggested on this mailing list a way to control whether redirects are followed but due to lack of response I have not done anything with it so far. Ok. The use case that could require to not follow silently or to follow silently but still leaving so kind of trace of redirects is a project I am currently working on : http://wiki.github.com/DavidBruant/linkChecker/ This is still very experimental (and a mess !) and not really ready to be deployed on actual websites. But the idea is to execute some JS on the client side and create a report of all resource links that can be found. Because it is run on the client side, if some content brought asynchronously contains links, these can be tested too (what is not true about this static checker : http://validator.w3.org/checklink). I think that the clients of my library could be interested in knowing if some links involve none or one or a lot of redirects. Redirects imply back and forth communication between client and server, as a consequence, they can affect performance of applications. For that reason, it could be interesting for me to provide the number of redirects and the different intermediate locations in the report. It would be a good way to provide a full analysis of the HTTP traffic. Yeah. Control over redirects would be cool to have to lengthen shortened URLs too. I think I will wait a bit with adding it until implementations of the features currently in the XHR2 draft are more stable though. Especially since last I asked nobody was jumping up and down for it. :-) Would it be clearer if after Once all HTTP headers have been received and the asynchronous flag is true I added (and this is not an HTTP redirect)? I think that because receiving HTTP headers are chronologically the first thing that happens, it could be the first written : Once all HTTP headers have been received and the asynchronous flag is true if it is an HTTP redirect then blabla if it is not, blabla. Well, theoretically you can detect a redirect before all HTTP headers of a response have been received. Regardless, I'll clarify the situation. Now I know that the semantic of the HEADERS_RECEIVED state is not headers received, but headers of the expected/final resource received, I think it would deserve some sort of note at this (http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#headers-received-state) moment to explain that it is not only a matter of recieving some/any headers, but there is also the notion of final/expected resource. Good point. I'm in the middle of other edits at the moment, but I will get to this after those. If the behavior has changed between XHR and XHR2, how authors can know what version is implemented by user agents ? In other words, is there a way defined by the spec to make the difference between a XHR conforming user agent and a XHR2 conforming user agent since the interface has the same name (XMLHttpRequest) ? No, because in general user agents do not implement everything from one or the other. E.g. a couple of user agents implemented features from XHR2 but are not at all conforming to XHR1 requirements that did not change in XHR2. Implementations evolve organically, not in concrete steps. So, why having two specifications in a working draft state ? Wouldn't it be easier for maintenability of the specs to have only the XHR2 spec and notes about legacy behaviors (and attributes/methods) ? Will XHR1 reach the recommandation state one day ? Will it make sense ? Since recently both specifications are created from the same source document so maintenance is no longer an issue for me. Some people see value in XHR1 and since the cost of maintaining it is now very low I have no problem pushing it forward. If it turns out that eventually we have two interoperable implementations of XHR2 we could decide to abandon further development of XHR1 I suppose, but there's no real need to decide any of that now. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR
On Wed, 27 Jan 2010 16:30:37 +0100, Pedro Santos pedros...@gmail.com wrote: Hi, I'm have a question about the XmlHttpRequest, can I use the same instance for several requests? Currently I know frameworks that maintain a pool of those objects, and after every call, they invoke the abort method [1], that switch the state to UNSENT, and use the same XmlHttpRequest instance for other requests. The problem is that the error flag get true, and the devs tools report the request with error. Can it be done in other ways? You can just invoke the open() method directly. That ought to work. I'm not sure why developer tools would report an error for invoking the abort() method though. That sounds like a bug. [1] http://www.w3.org/TR/XMLHttpRequest/#the-abort-method -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] New api request
On Fri, 29 Jan 2010 14:29:23 +0100, Pedro Santos pedros...@gmail.com wrote: Hi, how interest is for you develop new APIs in order to enable a reuse of the XMLHttpRequest objects, without the need to call abort method? No need to ask questions twice :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR LC comment: header encoding
On Tue, 05 Jan 2010 13:49:55 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Apart from the obvious worry of switching away from a behavior that the vast majority of UAs currently implement, with the ensuing potential for website breakage, sounds fine... I know... Though Opera not having received bug reports so far on this issue gives me some hope, since we have received lots of other bug reports on far more minor details starting very early on. The editor drafts of XHR1 and XHR2 now include the change. This also moved things away from being defined in Unicode to a combination of bytes and ASCII. Please let me know if you (i.e. anyone reading this thread) have any editorial suggestions on my changes or if I missed something while making the edits. Specifically search for inflate and deflate throughout the drafts: http://dev.w3.org/2006/webapi/XMLHttpRequest/ http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Or review the diff of xhr-source: http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/xhr-source.diff?r1=1.6r2=1.7f=h Kind regards, -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)
On Wed, 16 Dec 2009 20:46:03 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 16, 2009 at 9:37 AM, Ian Hickson i...@hixie.ch wrote: On another note, while reading the spec I noticed that no task is queued to updated responseText. Does that mean that if I check it continually in a tight loop within a task, I can see it change? I think the spec should say that when data arrives from the network, a task should be queued. When this task runs, it should perform the following steps synchronously: 1. Update .responseText 2. If readystate is not yet 3, set it to 3 and fire readystatechange This would dispatch readystatechange to often. The specification sides with IE/Opera here rather than WebKit/Gecko. 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired within the past 50ms This is already required elsewhere. I suppose I could try to merge the two, would that be useful? -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] XMLHttpRequest specification lacks security considerations
On Tue, 19 Jan 2010 08:01:12 +0100, Thomas Roessler t...@w3.org wrote: With apologies for the belated Last Call comment -- the XMLHttpRequest specification http://www.w3.org/TR/XMLHttpRequest/ ... doesn't have meaningful security considerations. I actually removed that section altogether in the editors draft. Section 3 should at the very least spell out: - Somewhat detailed considerations around CONNECT, TRACE, and TRACK (flagged in the text of the specification, but not called out in the security section; 4.6.1). What is the reason for duplicating this information? - Considerations around DNS rebinding. Why would these be specific to XMLHttpRequest? - Some explanation for the security reasons that are mentioned in section 4.6.2 (setRequestHeader). Maybe removing security reasons would be better? Providing rationale for each part of the specification would make it very big. - The rationale for the handling of HTTP redirects in section 4.6.4. I agree that this should be clarified, though I do not see why it should be mentioned in a separate section as well. - The fact that this specification normatively defines the same-origin policy as it applies to network access within browsers (section 4.6.1; though that mostly refers to HTML5 these days) It does not define the policy. It just uses it. Related to this, what is the rationale for making the following (explicitly security-relevant) conformance clauses SHOULD, not MUST? ** 4.6.1 If method is a case-sensitive match for CONNECT, TRACE, or TRACK the user agent should raise a SECURITY_ERR exception and terminate these steps. If the origin of url is not same origin with the XMLHttpRequest origin the user agent should raise a SECURITY_ERR exception and terminate these steps. ** 4.6.2 For security reasons, these steps should be terminated if header is an ASCII case-insensitive match for one of the following headers: ... Early on we agreed that all security-relevant conformance clauses should be SHOULD and not MUST so that implementors could ignore them in specific contexts. E.g. extensions. I would personally be fine with making these MUST. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] same-origin request event rules are underspecified
On Tue, 19 Jan 2010 08:00:19 +0100, Thomas Roessler t...@w3.org wrote: What does does not violate security mean? Is a same origin redirect the only redirect that's considered to not violate security? Yeah, this was old text that was never updated to match reality. Thanks for pointing it out! (Fixed for both XHR1 and XHR2, which have slightly different text as XHR2 deals with cross-origin redirects.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Sat, Jan 30, 2010 at 10:31, Ian Hickson i...@hixie.ch wrote: Right now, today, if I were to expose a WebSocket service on my Dreamhost shared server, I could do so without any trouble. If we used a scheme such as the one described above using a policy file, anyone else also hosting their site on the same server could grant access to my server to their scripts on their page. Whether this is a technical or administrative issue, it's an issue we have to handle today. If you only allow the policy file from being read from a single port and that port is controlled by the service provider, then it is possible to administrate this (together with other measures). With both flash and Silverlight you have that ability, serve the policy file from port 843 for flash and 943 for Silverlight and for flash say in the file that it may not be overridden. For flash, if the service provider doesn't administrate it, any other user of their site can serve their own policy file on any port and grant flash access to your Web Socket service. It is of course quite possible for flash to connect to your service and provide any origin it wants. In your shared host scenario another user can also try to grab your port before your program starts; shared resources require administration. A java applet can at least connect back to the same IP number as it was downloaded from, so another user on the shared host can publish such an applet. [snip] IMHO, yes. I understand that security is a tradeoff between risk and reward, but fundamentally, it seems to me that it is far off the risk/reward scale to design a system in such a way that a security problem cannot be fixed when it is discovered. Having the user agent cache the security policy and act on that cached version even after a security problem has been found prevents security problems from being fixed in a timely manner. Sure, it would cause a downtime, just like a misconfigured DNS entry can, so good administrators develop routines around it. But to talk about risk, one would have to talk about the chance of it happening, the cost of it when it happens and compare that to what the benefit is when it doesn't happen. I think it would have to happen quite often, or the service would have to cost quite a lot when it is down for it to make up for the extra cost of rewriting existing services. The general solution is to have an opt-in system like flash's policy files. This is not a possible solution if, as you suggest above, we send both requests simultaneously. It would be a slightly more complex solution, but as soon as the policy file is read, close the second port and don't allow another fast connect until the policy file has been read again if it didn't allow the access. It's also not possible in general, since as HTTP is also able to be used for this attack, one can simply tell the UA that the policy file is on the victim port, and have _that_ stage DOS the server instead of the actual Web Socket connection. Unless one specifies a specific port and only allows them to be downloaded from there (or uses a master file that says if is allowed to serve a policy file from another port). A good implementation can also avoid connecting to the policy port more than once at a time, but a good Web Socket implementation can't prevent the javascript from trying to connect to the same port many times since it can be legit for the higher level protocol. [snipped section about connecting to existing services] This is also not what Web Socket is designed to address, so it's not surprising that it can't handle this case. It also isn't a good protocol for implementing a generic document retrieval system, or peer-to-peer data transfer, or doing video multicast. These are not failings, per se, they just weren't use cases that Web Sockets was designed for. I expect the same two scenarios would come up in most cases where you want to use a web client against an existing tcp service. Absolutely. Web Sockets was specifically designed to make it impossible to connect to an existing TCP service, in fact, specifically to avoid situations such as poor policy file configurations allowing an SMTP server to be hijacked for sending spam. Yes, I understand that and I think you are throwing out the baby with the bathwater here, considering that this is how Silverlight and Flash works and html5 competes in many ways with them. The WebSocket protocol services would also be vulnerable to malicious code and instead of just having one implementation in each web browser that matches the origin with the port to see if a connection is allowed, that code would have to be added to each WebSocket protocol service and perhaps by less skilled programmers than the browser developers. I don't understand the attack scenario here. Can you elaborate? I'm just saying that instead of the (four?) big browser implementors adding support for some policy file and plain old TCP sockets,
ISSUE-113 (resize): Clarify when resize events fire [DOM3 Events]
ISSUE-113 (resize): Clarify when resize events fire [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/113 Raised by: Doug Schepers On product: DOM3 Events Emails: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1017.html http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1061.html http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1248.html Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=227495 https://bugs.webkit.org/show_bug.cgi?id=17969
[XHR2] AnonXMLHttpRequest()
I'm not really convinced we need all of http://dev.w3.org/2006/waf/UMP/ to handle the simple use case it is for. I think UMP can be layered on top of CORS by simply letting the origin be a unique identifier and always have the credentials flag be false. A new constructor could be used for XMLHttpRequest -- maybe called AnonXMLHttpRequest() -- to enable this behavior. Since most people in the WG seem to think we should have both UMP and CORS this solution seems much more straightforward and practical. Thoughts? -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)
On Sun, Jan 31, 2010 at 5:09 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 16 Dec 2009 20:46:03 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 16, 2009 at 9:37 AM, Ian Hickson i...@hixie.ch wrote: On another note, while reading the spec I noticed that no task is queued to updated responseText. Does that mean that if I check it continually in a tight loop within a task, I can see it change? I think the spec should say that when data arrives from the network, a task should be queued. When this task runs, it should perform the following steps synchronously: 1. Update .responseText 2. If readystate is not yet 3, set it to 3 and fire readystatechange This would dispatch readystatechange to often. The specification sides with IE/Opera here rather than WebKit/Gecko. Huh? This would only fire readystatechange for readyState=3 once per request. That doesn't seem too often. 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired within the past 50ms This is already required elsewhere. I suppose I could try to merge the two, would that be useful? The main point of my email was that responseText should never change other than from the main event loop. I.e. doing xhr.responseText == xhr.responseText should always return true. / Jonas
Re: [XHR] New api request
Why not create a new XMLHttpRequest object for each request? - James On Jan 29, 2010 5:31 AM, Pedro Santos pedros...@gmail.com wrote: Hi, how interest is for you develop new APIs in order to enable a reuse of the XMLHttpRequest objects, without the need to call abort method? -- Pedro Henrique Oliveira dos Santos
Re: Seeking implementation data for CORS and UMP
On Sun, Jan 31, 2010 at 7:36 AM, Arthur Barstow art.bars...@nokia.com wrote: All, I added an Implementation section to the CORS and UMP comparison wiki but it is currently empty: http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP#Implementation_Data What is the latest implementation status for these specs? I will add response data to the wiki (but feel free to do so yourself or let me know if you need write access). Firefox 3.5 and newer implements CORS for use with XMLHttpRequest and @font-face. At the time of the implementation we didn't implement the full spec with regards to redirects, but I know the spec has changed some since then, so I'm not sure what the exact status is now. / Jonas
Re: [XHR2] AnonXMLHttpRequest()
On Sun, Jan 31, 2010 at 1:50 PM, Anne van Kesteren ann...@opera.com wrote: I'm not really convinced we need all of http://dev.w3.org/2006/waf/UMP/ to handle the simple use case it is for. I think UMP can be layered on top of CORS by simply letting the origin be a unique identifier and always have the credentials flag be false. A new constructor could be used for XMLHttpRequest -- maybe called AnonXMLHttpRequest() -- to enable this behavior. Since most people in the WG seem to think we should have both UMP and CORS this solution seems much more straightforward and practical. Thoughts? What do you mean by unique identifier? / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm
Re: [XHR2] AnonXMLHttpRequest()
On Jan 31, 2010, at 1:50 PM, Anne van Kesteren wrote: I'm not really convinced we need all of http://dev.w3.org/2006/waf/UMP/ to handle the simple use case it is for. I think UMP can be layered on top of CORS by simply letting the origin be a unique identifier and always have the credentials flag be false. Why a unique identifier instead of Origin: null? A new constructor could be used for XMLHttpRequest -- maybe called AnonXMLHttpRequest() -- to enable this behavior. Or it could be a constructor parameter or some attributes that you set, though that would be a bit more work for object-capability subsets. Since most people in the WG seem to think we should have both UMP and CORS this solution seems much more straightforward and practical. Thoughts? I'm curious what practical differences there are between CORS with the credentials flag set to false and the origin set to null, and UMP. Are there any? Right now UMP doesn't support preflights, so we'd need to either add a no preflight requests flag, or ensure that AnonXMLHttpRequest cannot send any requests which would result in preflight. Note: in light of the above, I think AnonXMLHttpRequest would be almost the same as XDomainRequest, the only difference being that it would send Origin: null instead of the sender's actual Origin. Regards, Maciej
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote: 2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon *Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. I don't see a need to standardize anything solely for use by extensions. What we should ask is which icons are useful for Web content, since that is where we have the interoperability constraint. Extensions do not currently interoperate between different browsers, nor is this planned as far as I can tell, so they cannot be the sole use case for any part of a Web standard IMO. Regards, Maciej
