[Bug 15293] New: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://www.cnodejs.org WebSocket-Location: ws://www.cnodejs.org:8088/echo
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15293 Summary: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://www.cnodejs.org WebSocket-Location: ws://www.cnodejs.org:8088/echo Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://www.cnodejs.org WebSocket-Location: ws://www.cnodejs.org:8088/echo Posted from: 125.35.5.3 User agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; 360SE) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Bug in file system Api specification
Hi http://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the newFileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
Re: CfC: add Quota API to WebApps' charter; deadline December 20
Hi, (Sorry for my slow response, I'm in a half-vacation status) On Sun, Dec 18, 2011 at 12:19 AM, Charles McCathieNevile cha...@opera.comwrote: On Fri, 16 Dec 2011 10:10:45 +0100, Kinuko Yasuda kin...@chromium.org wrote: On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow art.bars...@nokia.com wrote: Hi Kinuko, All, Besides the Chromium team, I think it would be helpful if other browser vendors would state their level of interest for this API (e.g. would review drafts, prototype, deploy, etc.). We will at least review - in principle this is really useful for application developers. (Comment 1 - why does this need to use callbacks?) Thanks for the comment! This question could be interpreted two different ways: 1. Why this needs to be async? We wanted to make them async operations since querying the usage or updating the quota in the UA may require some blocking operations, like examining the actual disk usage or querying the backend database. 2. Why we use callbacks instead of events? I know there's a long history of callbacks vs events discussion, but the reason in our case was simple: The Quota API proposal was fleshed out along with the FileSystem API [1], which is the first storage API draft that has the concept of 'temporary' vs 'persistent' storage we wanted to introduce in the Quota API, and this motivated us to use the API notation similar to FileSystem API (i.e. callbacks). One of the obvious benefit of events is, in my understanding, in that way we could naturally implement progress events or abort method, both could be crucial in streaming processing, but in the quota case either one doen't seem to be really necessary. Events could also naturally allow multiple listeners but again this doesn't seem crucial in the quota API. I'm open to change this though if we have legitimate reasons strong enough to change existing chrome code. (I'll fork a new thread if this discussion could become longer) [1] dev.w3.org/2009/dap/file-system/file-dir-sys.html Kinuko - do you have a commitment for the Editor role and testing related tasks e.g. creating a test suite? Yes I'm willing to play the Editor role. As for the testing related tasks I'm not fully sure the necessary steps and deliverables, Making sure there are tests for the specification so it can be completed and anyone can use them to demonstrate interoperability between any two implementations... Thanks, several people also kindly told me what'd be the expected tasks. Given the basic nature of the spec I guess it doesn't need to be an enormous test suite - the most complex question is probably checking that it really works as advertised with different types of storage. (Although I am not sure what the quota would actually *mean* for a database). For database we have no way to express 'temporary' or 'persistent' in the current spec, so the UA needs to store its data either in temporary or persistent. In the current chrome implementation we treat all the data of Web SQL, IndexedDB and AppCache as 'temporary' storage data, i.e. they can store some data without showing user prompting but the data could get deleted when the remaining space becomes low. (I'm aware that this part needs to be fleshed out more in terms of interoperability.) but yes I'm willing to do the tasks that need to be done to move this forward. In light of the above explanation? Yes. cheers Chaals -AB On 12/13/11 7:23 AM, ext Arthur Barstow wrote: Subject corrected ... On 12/13/11 7:22 AM, Arthur Barstow wrote: As IanF mentioned before, Google would like to add a Quota API to WebApps' charter and Kinuko has now provided a link to a document that provides some details about this API: http://wiki.whatwg.org/wiki/Quotahttp://wiki.whatwg.org/wiki/**Quota http://wiki.whatwg.org/**wiki/Quotahttp://wiki.whatwg.org/wiki/Quota As such, this is a Call for Consensus to add this API to WebApps' charter (see [CharterChanges] for latest data on WebApps' charter update). If you have any comments or concerns about this proposal, please send them to public-webapps by December 20 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -AB [CharterChanges] http://www.w3.org/2008/ webapps/wiki/CharterChangeshttp://www.w3.org/2008/**webapps/wiki/CharterChanges ht**tp://www.w3.org/2008/webapps/**wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges Original Message Subject: Re: Quota API and WebApps [Was: Re: Consolidating charter changes] Date: Tue, 13 Dec 2011 17:22:38 +0900 From: ext Kinuko Yasuda kin...@chromium.org To: Arthur Barstow art.bars...@nokia.com CC: public-webapps public-webapps@w3.org, Ian Fette ife...@google.com Hi Arthur, On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow art.bars...@nokia.commailto:
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
As fun as this is, all this mud slinging is really not getting us anywhere useful. Lets go back an look at the options we have to divorce Widgets/XML Dig Sig from Elliptic Curve: 1. Remove ECC from XML Dig Sig (in my opinion, the right thing to do™): pros: - frees both XML Dig Sig and Widgets Dig Sig to progress to REC at full speed. - begins a pattern of divorcing signature algorithms from processing (a good thing, which avoids this kind of mess!) cons: - new small spec needed - XML Dig Sig missing an important algorithm. 2. Pointing to /latest/ Pros: - Always pointing to Rec - Conformance always bound to latest Rec Cons: - As XML Dig Sig does not include SHA-256, this does not currently help Widgets Dig Sig progress - Conformance always bound to latest Rec Kind regards, Marcos And because I was told by some that this is very entertaining… though I personally don't want to spend time arguing in circles (and around the main point which is to progress Widgets Dig Sig)…. So some parting words :) On Tuesday, December 20, 2011 at 5:49 PM, Charles McCathieNevile wrote: TL;DR: JC and Leonard are right. I'm sorry, but they are not. Pointing to a moving target makes any statement about conformance pretty much unusable in the real world. This is also bogus. I manage the conformance suites for WAC and for W3C Widgets, and the fact that we fix tests and patch specs every week is evidence otherwise. Almost all the standards I manage tests for are done (i.e., REC or close to / or equivalent in WAC), yet we continuously fix issues in both the tests and the specs. Which is significantly worse than having a statement of conformance to something known to contain errors and bugs. Leaving things broken is not in the interests of users or developers, and is bad business. One would not claim to conform to a broken test and would need to revise their conformance if a test is found to be broken after claiming conformance (hence, any claim to conformance is temporally bound and not forever). Furthermore, updates to software can again introduce regressions: hence, you constantly need to be checking if your software actually conforms because any update you make to software may break conformance (i.e., introduce a regression). This is common: http://my.opera.com/core/blog/2009/10/13/automated-testing-of-the-browser-core Browsers don't implement living standards. They implement something undefined for an open environment where people are continually innovating, and they make considerable and expensive efforts to tell the community what it is they implement. If they implement the HTML5 spec, then they are implementing a living standard. You can dress the mutton as lamb all you want, but the fact remains that HTML5 is a living standard. Browsers like Opera who have commercial enterprise customers work with those customers to establish sensible conformance requirements that take into account the evolutionary nature of the web (rather than arbitrary stacks of requirements that happened to be easy to test), but neither side wants a Statement of Work that doesn't actually clarify what is expected to be delivered under a legally binding contract. I understand this business requirement, but it's flawed (or disingenuous): It makes no sense, for instance, to say to a costumer we are going to implement the june 10th version of HTML5 because that version might be missing feature X (or feature X was badly specified, or changes, whatever). Also, any conformance tests will have been updated after June 10th, so you are screwed anyway (unless you took a snapshot of the test suite). But then when you ship your June 10 snapshot, developers cry foul because the feature does not match the behavior of the latest version of HTML5… So then your customer is pissed off because you delivered what was in your contract, but no one wants to use the software because it's outdated and buggy (you tell your developers oh! it's based on an old, outdated, spec… sorry guys, we were under contract to deliver something outdated to you… have fun working around it!… and you tell your client, oh, that's what you paid for. Thanks! enjoy the mass of angry devs and users, suckers!). Meanwhile, your competitor did the right thing and kept up with the latest spec: they take all the developers and leave your ecosystem for dead. I.e., snapshotting is a nice form of commercial suicide, and you will just have to catch up. Sure, you will make a quick buck, but it will just lead to a market failure. Better is to have a maintenance agreement with your customer: ok! we will try to keep up with HTML5 for the next year… that will be X Million dollars please. A lack of stability and precision about which version of a specification is meant also makes it harder to get a decent
Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]
Hi Brona, For mostly historical reasons, WebApps' File* specs still use Tracker rather than Bugzilla (and IIRC, Arun also uses the list archive as well as the spec itself to track issues for the File API spec): http://www.w3.org/2008/webapps/track/products For consistency, it would be good to move these specs to Bugzilla but I also don't want to create any make work for the Editors. (Arun, Jonas, EricU - if you want Bugzilla components for these specs, please let me know and I'll ask MikeSmith to create them.) -AB On 12/21/11 3:21 AM, ext Bronislav Klučka wrote: Hi http://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the newFileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
Re: Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]
Hi Arthur, I do not need them :) that's mainly for editors to keep track in one place :) I just suggest this bug to be fixed and it's silly to spam whole forum because of it :) (I do not have access to file a bug in this W3C tracking tool) Brona On 21.12.2011 13:05, Arthur Barstow wrote: Hi Brona, For mostly historical reasons, WebApps' File* specs still use Tracker rather than Bugzilla (and IIRC, Arun also uses the list archive as well as the spec itself to track issues for the File API spec): http://www.w3.org/2008/webapps/track/products For consistency, it would be good to move these specs to Bugzilla but I also don't want to create any make work for the Editors. (Arun, Jonas, EricU - if you want Bugzilla components for these specs, please let me know and I'll ask MikeSmith to create them.) -AB On 12/21/11 3:21 AM, ext Bronislav Klučka wrote: Hi http://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the newFileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
TLR, FH, XMLSecWG, On 12/21/11 6:03 AM, ext Marcos Caceres wrote: Lets go back an look at the options we have to divorce Widgets/XML Dig Sig from Elliptic Curve: 1. Remove ECC from XML Dig Sig (in my opinion, the right thing to do™): pros: - frees both XML Dig Sig and Widgets Dig Sig to progress to REC at full speed. - begins a pattern of divorcing signature algorithms from processing (a good thing, which avoids this kind of mess!) cons: - new small spec needed - XML Dig Sig missing an important algorithm. Based on a quick scan of the XMLSec WG's mail archive [2], it appears that WG has known about potential IP issues related to Certicom/RIM and ECC for almost 3 years. As such, surely the WG has already discussed refactoring the XMLSig spec in a way like Marcos and I proposed. Would you please explain why the WG objects to such refactoring (or provide a link(s) to the related discussion)? As an FYI for the XMLSec WG members, note that another widget spec was blocked for two years because of a PAG [1] so it's quite understandable that having widgets-digsig blocked by YA PAG creates concerns for some WG members, especially given the ECC PAG Chair's pessimistic view [3] of a quick PAG resolution. -Thanks, AB [1] http://www.w3.org/2009/11/widgets-pag/pagreport.html [2] http://www.w3.org/Search/Mail/Public/search?keywords=hdr-1-name=subjecthdr-1-query=certicomindex-grp=Public_FULLindex-type=ttype-index=public-xmlsec [3] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1540.html
Re: [XHR2] timeout
Are any user agents other than IE8+ currently implementing or have implemented XHR2 timeout? https://bugs.webkit.org/show_bug.cgi?id=74802 I have a couple of things I wanted to question, which may or may not result in clarification in the spec. 1. The spec says the timeout should fire after the specified number of milliseconds has elapsed since the start of the request. I presume this means literally that, with no bearing on whether or not data is coming over the wire? 2. Given we have progress events, we can determine that data is coming over the wire and react accordingly (though in an ugly fashion, semantically). E.g., the author can disable the timeout or increase the timeout. Is that use case possible? In other words, should setting the timeout value during an active request reset the timer? Or should the timer always be basing its elapsed time on the start time of the request + the specified timeout value (an absolute point in the future)? I understand the language in the spec is saying the latter, but perhaps could use emphasis that the timeout value can be changed mid-request. Furthermore, if the timeout value is set to a value 0 but less than the original value, and the elapsed time is past the (start_time + timeout), do we fire the timeout or do we effectively disable it? 3. Since network stacks typically operate w/ timeouts based on data coming over the wire, what about a different timeout attribute that fires a timeout event when data has stalled, e.g., dataTimeout? I think this type of timeout would be more desirable by authors to have control over for async requests, since today it's kludgey to try and simulate that with timers/progress events + abort(). Whereas with the overall request timeout, library authors already simulate that easily with timers + abort() in the async context. For sync requests in worker contexts, I can see a dataTimeout as being heavily desired over a simple request timeout. Thanks, Jarred
Re: [XHR2] timeout
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls jar...@webkit.org wrote: 1. The spec says the timeout should fire after the specified number of milliseconds has elapsed since the start of the request. I presume this means literally that, with no bearing on whether or not data is coming over the wire? Right. 2. Given we have progress events, we can determine that data is coming over the wire and react accordingly (though in an ugly fashion, semantically). E.g., the author can disable the timeout or increase the timeout. Is that use case possible? In other words, should setting the timeout value during an active request reset the timer? Or should the timer always be basing its elapsed time on the start time of the request + the specified timeout value (an absolute point in the future)? I understand the language in the spec is saying the latter, but perhaps could use emphasis that the timeout value can be changed mid-request. http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f Furthermore, if the timeout value is set to a value 0 but less than the original value, and the elapsed time is past the (start_time + timeout), do we fire the timeout or do we effectively disable it? The specification says has passed which seems reasonably clear to me. I.e. you fire it. 3. Since network stacks typically operate w/ timeouts based on data coming over the wire, what about a different timeout attribute that fires a timeout event when data has stalled, e.g., dataTimeout? I think this type of timeout would be more desirable by authors to have control over for async requests, since today it's kludgey to try and simulate that with timers/progress events + abort(). Whereas with the overall request timeout, library authors already simulate that easily with timers + abort() in the async context. For sync requests in worker contexts, I can see a dataTimeout as being heavily desired over a simple request timeout. So if you receive no octet for dataTimeout milliseconds you get the timeout event and the request terminates? Sounds reasonable. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls jar...@webkit.org wrote: 1. The spec says the timeout should fire after the specified number of milliseconds has elapsed since the start of the request. I presume this means literally that, with no bearing on whether or not data is coming over the wire? Right. 2. Given we have progress events, we can determine that data is coming over the wire and react accordingly (though in an ugly fashion, semantically). E.g., the author can disable the timeout or increase the timeout. Is that use case possible? In other words, should setting the timeout value during an active request reset the timer? Or should the timer always be basing its elapsed time on the start time of the request + the specified timeout value (an absolute point in the future)? I understand the language in the spec is saying the latter, but perhaps could use emphasis that the timeout value can be changed mid-request. http://dvcs.w3.org/hg/xhr/rev/**2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/2ffc908d998f Brilliant, no doubts about it now ;) Furthermore, if the timeout value is set to a value 0 but less than the original value, and the elapsed time is past the (start_time + timeout), do we fire the timeout or do we effectively disable it? The specification says has passed which seems reasonably clear to me. I.e. you fire it. Cool, agreed. 3. Since network stacks typically operate w/ timeouts based on data coming over the wire, what about a different timeout attribute that fires a timeout event when data has stalled, e.g., dataTimeout? I think this type of timeout would be more desirable by authors to have control over for async requests, since today it's kludgey to try and simulate that with timers/progress events + abort(). Whereas with the overall request timeout, library authors already simulate that easily with timers + abort() in the async context. For sync requests in worker contexts, I can see a dataTimeout as being heavily desired over a simple request timeout. So if you receive no octet for dataTimeout milliseconds you get the timeout event and the request terminates? Sounds reasonable. Correct. Same timeout exception/event shared with the request timeout attribute, and similar setter/getter steps; just having that separate criteria for triggering it. -- Anne van Kesteren http://annevankesteren.nl/ Thanks, Jarred
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Hi Art, the pessimistic XMLSECPAG chair told you that it wouldn't resolve within days. But I hope to have a clear view and plan by the end of January. Executing that plan may take some time. Plan is to resolve until end of March, if everything goes well. Well meaning a decision of the PAG and the execution thereof, not necessarily finding a way to destroy the disclosed patents. The three years can be explained by very promising negotiations with Certicom on an RF license that finally failed because of an overreaching clause on defensive suspension. We were really close to a resolution. Best, Rigo XMLSEC PAG Chair On Wednesday 21 December 2011 09:35:08 Arthur Barstow wrote: As an FYI for the XMLSec WG members, note that another widget spec was blocked for two years because of a PAG [1] so it's quite understandable that having widgets-digsig blocked by YA PAG creates concerns for some WG members, especially given the ECC PAG Chair's pessimistic view [3] of a quick PAG resolution.
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? In short, yup. I do need to write a nice example that shows how it all fits together (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173). Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all over...or is that what you were specifically trying to avoid with your distinction about the type of boundary? Anything special there about blocking for stylesheets or script? Also, I might have missed this, but it seems like you would still have access to document object? I understand its not a security related boundary you are describing but would it be possible to just evaluate the meaning of document based on your position so as to avoid the confusion that will likely cause? There are no workers or any special considerations for things that aren't mentioned. It is just a DOM subtree. I wonder if there's a convention of stating this somehow without actually re-describing how HTML/DOM works? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? :DG -Brian On Dec 20, 2011 7:52 PM, Edward Oapos;Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Anyway, thanks for the writeup, and have a wonderful break! Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
Re: Bug in file system Api specification
Bronislav: Thanks for the tip; it's already fixed in the latest editor's draft, so the fix will get published the next time the document is. See the latest at http://dev.w3.org/2009/dap/file-system/file-dir-sys.html. Eric On Wed, Dec 21, 2011 at 12:21 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Hi http://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the new FileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
[cors] Simple Header question
There are a number of standard headers that aren't listed as simple headers but which I am suspecting are allowed in any case via some other principle: Accept-Charset Accept-Encoding Connection Host Referer User-Agent Cookie Is this true or some or all of these? If so, how was I supposed to figure it out?
Re: [XHR2] timeout
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout should fire after the specified
number of
milliseconds has elapsed since the start of the request. I
presume this means literally that, with no bearing on whether or
not data is coming over the wire?
Right.
2. Given we have progress events, we can determine that data is
coming
over the wire and react accordingly (though in an ugly fashion,
semantically). E.g., the author can disable the timeout or
increase the timeout. Is that use case possible? In other
words, should setting the timeout value during an active request
reset the timer? Or should the
timer always be basing its elapsed time on the start time of the
request + the specified timeout value (an absolute point in the
future)? I
understand the language in the spec is saying the latter, but
perhaps could use emphasis that the timeout value can be changed
mid-request.
http://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
Brilliant, no doubts about it now ;)
Furthermore, if the timeout value is set to a value 0 but less
than the original value, and the elapsed time is past the
(start_time + timeout), do we fire the timeout or do we
effectively disable it?
The specification says has passed which seems reasonably clear to
me. I.e. you fire it.
Cool, agreed.
3. Since network stacks typically operate w/ timeouts based on data
coming over the wire, what about a different timeout attribute
that fires a timeout event when data has stalled, e.g.,
dataTimeout? I think this type of timeout would be more
desirable by authors to have control over for
async requests, since today it's kludgey to try and simulate
that with
timers/progress events + abort(). Whereas with the overall request
timeout, library authors already simulate that easily with
timers + abort() in the async context. For sync requests in
worker contexts, I can see a dataTimeout as being heavily
desired over a simple request timeout.
So if you receive no octet for dataTimeout milliseconds you get the
timeout event and the request terminates? Sounds reasonable.
Correct. Same timeout exception/event shared with the request timeout
attribute, and similar setter/getter steps; just having that separate
criteria for triggering it.
Is there really need for dataTimeout? You could easily use progress
events and .timeout to achieve similar functionality.
This was the reason why I originally asked that .timeout can be set also
when XHR is active.
xhr.onprogress = function() {
this.timeout += 250;
}
(timeout is being implemented in Gecko)
-Olli
--
Anne van Kesteren
http://annevankesteren.nl/
Thanks,
Jarred
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout should fire after the specified
number of
milliseconds has elapsed since the start of the request. I
presume this means literally that, with no bearing on whether or
not data is coming over the wire?
Right.
2. Given we have progress events, we can determine that data is
coming
over the wire and react accordingly (though in an ugly fashion,
semantically). E.g., the author can disable the timeout or
increase the timeout. Is that use case possible? In other
words, should setting the timeout value during an active request
reset the timer? Or should the
timer always be basing its elapsed time on the start time of the
request + the specified timeout value (an absolute point in the
future)? I
understand the language in the spec is saying the latter, but
perhaps could use emphasis that the timeout value can be changed
mid-request.
http://dvcs.w3.org/hg/xhr/rev/**__2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
Brilliant, no doubts about it now ;)
Furthermore, if the timeout value is set to a value 0 but less
than the original value, and the elapsed time is past the
(start_time + timeout), do we fire the timeout or do we
effectively disable it?
The specification says has passed which seems reasonably clear to
me. I.e. you fire it.
Cool, agreed.
3. Since network stacks typically operate w/ timeouts based on data
coming over the wire, what about a different timeout attribute
that fires a timeout event when data has stalled, e.g.,
dataTimeout? I think this type of timeout would be more
desirable by authors to have control over for
async requests, since today it's kludgey to try and simulate
that with
timers/progress events + abort(). Whereas with the overall request
timeout, library authors already simulate that easily with
timers + abort() in the async context. For sync requests in
worker contexts, I can see a dataTimeout as being heavily
desired over a simple request timeout.
So if you receive no octet for dataTimeout milliseconds you get the
timeout event and the request terminates? Sounds reasonable.
Correct. Same timeout exception/event shared with the request timeout
attribute, and similar setter/getter steps; just having that separate
criteria for triggering it.
Is there really need for dataTimeout? You could easily use progress events
and .timeout to achieve similar functionality.
This was the reason why I originally asked that .timeout can be set also
when XHR is active.
xhr.onprogress = function() {
this.timeout += 250;
}
Then why have timeout at all? Your workaround for a native dataTimeout is
analogous to using a setTimeout + xhr.abort() to simulate the request
timeout.
I can tell you why I believe we should have dataTimeout in addition to
timeout:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet would need
to be amended to maintain the time of the start of the request and
calculate the difference between that and the time the progress event fired
+ your timeout value:
xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
A dataTimeout is a buffered timer that's reset on each octet of data
that's received; a sliding window of elapsed time before timing out. Every
time the above snippet is calculated, it becomes more and more erroneous;
the margin of error increases because of time delays of JS events being
dispatched, etc.
2. Synchronous requests in worker contexts have no way to simulate this
behavior, for request timeouts nor for data timeouts. Most of the network
stacks in browsers have a default data timeout (e.g. 10 seconds) but
allowing the author to override that timeout has value I'd think. With
that said... synchronous requests? What are those? :)
(timeout is being implemented in Gecko)
Awesome!
-Olli
--
Anne van Kesteren
http://annevankesteren.nl/
Thanks,
Jarred
Re: [cors] Simple Header question
On Wed, 21 Dec 2011 19:24:19 +0100, Benson Margulies bimargul...@gmail.com wrote: There are a number of standard headers that aren't listed as simple headers but which I am suspecting are allowed in any case via some other principle: Accept-Charset Accept-Encoding Connection Host Referer User-Agent Cookie Is this true or some or all of these? If so, how was I supposed to figure it out? Simple headers is only for headers controlled by the author, not the user agent. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] timeout
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren
ann...@opera.com mailto:ann...@opera.com
mailto:ann...@opera.com mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org
mailto:jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout should fire after the specified
number of
milliseconds has elapsed since the start of the request. I
presume this means literally that, with no bearing on
whether or
not data is coming over the wire?
Right.
2. Given we have progress events, we can determine that
data is
coming
over the wire and react accordingly (though in an ugly
fashion,
semantically). E.g., the author can disable the timeout or
increase the timeout. Is that use case possible? In other
words, should setting the timeout value during an active
request
reset the timer? Or should the
timer always be basing its elapsed time on the start
time of the
request + the specified timeout value (an absolute point
in the
future)? I
understand the language in the spec is saying the
latter, but
perhaps could use emphasis that the timeout value can be
changed
mid-request.
http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/__rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
Brilliant, no doubts about it now ;)
Furthermore, if the timeout value is set to a value 0
but less
than the original value, and the elapsed time is past the
(start_time + timeout), do we fire the timeout or do we
effectively disable it?
The specification says has passed which seems reasonably
clear to
me. I.e. you fire it.
Cool, agreed.
3. Since network stacks typically operate w/ timeouts
based on data
coming over the wire, what about a different timeout
attribute
that fires a timeout event when data has stalled, e.g.,
dataTimeout? I think this type of timeout would be more
desirable by authors to have control over for
async requests, since today it's kludgey to try and simulate
that with
timers/progress events + abort(). Whereas with the
overall request
timeout, library authors already simulate that easily with
timers + abort() in the async context. For sync requests in
worker contexts, I can see a dataTimeout as being heavily
desired over a simple request timeout.
So if you receive no octet for dataTimeout milliseconds you
get the
timeout event and the request terminates? Sounds reasonable.
Correct. Same timeout exception/event shared with the request
timeout
attribute, and similar setter/getter steps; just having that
separate
criteria for triggering it.
Is there really need for dataTimeout? You could easily use progress
events and .timeout to achieve similar functionality.
This was the reason why I originally asked that .timeout can be set
also when XHR is active.
xhr.onprogress = function() {
this.timeout += 250;
}
Then why have timeout at all? Your workaround for a native dataTimeout
is analogous to using a setTimeout + xhr.abort() to simulate the request
timeout.
I can tell you why I believe we should have dataTimeout in addition to
timeout:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet would
need to be amended to maintain the time of the start of the request
and calculate the difference between that and the time the progress
event fired + your timeout value:
xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
A dataTimeout is a buffered timer that's reset on each octet of data
that's received; a sliding window of elapsed time before timing out.
Every time the above snippet is calculated, it becomes more and
more erroneous; the margin of error increases because of time delays
of JS events being dispatched, etc.
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR requests to continue? This would time out as soon as that
happened.
This particular snippet seems to be trying to do work that the browser
should be taking care of. If there's really a use case for must receive
some data every N milliseconds, in addition to .timeout (the whole
request must complete in N milliseconds), then it seems better to add a
separate timeout property for that instead of encouraging people to
implement timeouts by hand. It would also work fine for synchronous
requests.
(I don't know what the use cases are for this, though.)
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet would need
to be amended to maintain the time of the start of the request and
calculate the difference between that and the time the progress event fired
+ your timeout value:
xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
This, at least, doesn't seem interesting. I don't think it's worthwhile
to add new APIs just so people don't have to do simple math.
var now = new Date().getTime();
xhr.timeout = now - requestStart + timeoutLength;
This is simple and clean; there's no need to complicate the platform for
this.
--
Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:20 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR requests to continue? This would time out as soon as that
happened.
This particular snippet seems to be trying to do work that the browser
should be taking care of. If there's really a use case for must receive
some data every N milliseconds, in addition to .timeout (the whole
request must complete in N milliseconds), then it seems better to add a
separate timeout property for that instead of encouraging people to
implement timeouts by hand. It would also work fine for synchronous
requests.
(I don't know what the use cases are for this, though.)
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.orgwrote:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet would need
to be amended to maintain the time of the start of the request and
calculate the difference between that and the time the progress event
fired
+ your timeout value:
xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
This, at least, doesn't seem interesting. I don't think it's worthwhile
to add new APIs just so people don't have to do simple math.
var now = new Date().getTime();
xhr.timeout = now - requestStart + timeoutLength;
This is simple and clean; there's no need to complicate the platform for
this.
You sound really self-conflicted based on how you started your message vs.
how you ended it.
--
Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls jar...@webkit.org wrote: You sound really self-conflicted based on how you started your message vs. how you ended it. Please be less vague. -- Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:Olli.Pettay@helsinki.**fi olli.pet...@helsinki.fi wrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren
ann...@opera.com mailto:ann...@opera.com
mailto:ann...@opera.com mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org
mailto:jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout should fire after the
specified
number of
milliseconds has elapsed since the start of the request. I
presume this means literally that, with no bearing on
whether or
not data is coming over the wire?
Right.
2. Given we have progress events, we can determine that
data is
coming
over the wire and react accordingly (though in an ugly
fashion,
semantically). E.g., the author can disable the timeout or
increase the timeout. Is that use case possible? In other
words, should setting the timeout value during an active
request
reset the timer? Or should the
timer always be basing its elapsed time on the start
time of the
request + the specified timeout value (an absolute point
in the
future)? I
understand the language in the spec is saying the
latter, but
perhaps could use emphasis that the timeout value can be
changed
mid-request.
http://dvcs.w3.org/hg/xhr/rev/**2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/__2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/__2ffc908d998f
http://dvcs.w3.org/hg/xhr/__**rev/2ffc908d998fhttp://dvcs.w3.org/hg/xhr/__rev/2ffc908d998f
http://dvcs.w3.org/hg/xhr/**rev/2ffc908d998fhttp://dvcs.w3.org/hg/xhr/rev/2ffc908d998f
Brilliant, no doubts about it now ;)
Furthermore, if the timeout value is set to a value 0
but less
than the original value, and the elapsed time is past the
(start_time + timeout), do we fire the timeout or do we
effectively disable it?
The specification says has passed which seems reasonably
clear to
me. I.e. you fire it.
Cool, agreed.
3. Since network stacks typically operate w/ timeouts
based on data
coming over the wire, what about a different timeout
attribute
that fires a timeout event when data has stalled, e.g.,
dataTimeout? I think this type of timeout would be more
desirable by authors to have control over for
async requests, since today it's kludgey to try and
simulate
that with
timers/progress events + abort(). Whereas with the
overall request
timeout, library authors already simulate that easily with
timers + abort() in the async context. For sync requests
in
worker contexts, I can see a dataTimeout as being heavily
desired over a simple request timeout.
So if you receive no octet for dataTimeout milliseconds you
get the
timeout event and the request terminates? Sounds reasonable.
Correct. Same timeout exception/event shared with the request
timeout
attribute, and similar setter/getter steps; just having that
separate
criteria for triggering it.
Is there really need for dataTimeout? You could easily use progress
events and .timeout to achieve similar functionality.
This was the reason why I originally asked that .timeout can be set
also when XHR is active.
xhr.onprogress = function() {
this.timeout += 250;
}
Then why have timeout at all? Your workaround for a native dataTimeout
is analogous to using a setTimeout + xhr.abort() to simulate the request
timeout.
I can tell you why I believe we should have dataTimeout in addition to
timeout:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet would
need to be amended to maintain the time of the start of the request
and calculate the difference between that and the time the progress
event fired + your timeout value:
xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout;
A dataTimeout is
Re: [XHR2] timeout
(11/12/21 23:47), Anne van Kesteren wrote: On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls jar...@webkit.org wrote: 1. The spec says the timeout should fire after the specified number of milliseconds has elapsed since the start of the request. I presume this means literally that, with no bearing on whether or not data is coming over the wire? Right. Does this need to be clarified? follow the same-origin request event rules has the premise as data becomes available and when the user interferes with the request and timeout seems a bit special here.
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.org wrote: On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote: 1. Clean code, which is better for authors and the web platform. To achieve the same results as a native dataTimeout, your snippet would need to be amended to maintain the time of the start of the request and calculate the difference between that and the time the progress event fired + your timeout value: xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout; This, at least, doesn't seem interesting. I don't think it's worthwhile to add new APIs just so people don't have to do simple math. var now = new Date().getTime(); xhr.timeout = now - requestStart + timeoutLength; This is simple and clean; there's no need to complicate the platform for this. And now writing timers by hand is okay? First, this is a response to the specific point above about clean code, not an argument that using timers this way is necessarily a good idea. Computing a relative timeout delay just isn't complicated. Second, my note to Olli was about using onprogress, not setTimeout. His onprogress example might encounter problems if the UA suspends scripts but not transfers (in order to give predictable battery usage for backgrounded apps). Using setTimeout for completion timeouts might be okay, since the UA would probably also delay timers if it was suspending scripts. The point is, whatever reasons everyone agreed to have timeout, the same reasons apply to dataTimeout. Otherwise they both might as well be dropped. One possible reason--which came to mind writing the above--is that setTimeout delays can be arbitrarily longer than requested. If a UA suspends scripts for ten minutes (eg. the user switches tasks on his phone), and the timeout is setTimeout(f, 60*5), it could result in a 15-minute-long timeout, with the timeout never triggering while backgrounded (so the UA keeps trying unnecessarily). That doesn't automatically means that a data received timeout is needed, though; it still needs use cases. -- Glenn Maynard
Re: [XHR2] timeout
On Wed, Dec 21, 2011 at 3:54 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.orgwrote: On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org wrote: 1. Clean code, which is better for authors and the web platform. To achieve the same results as a native dataTimeout, your snippet would need to be amended to maintain the time of the start of the request and calculate the difference between that and the time the progress event fired + your timeout value: xhr.timeout = ((new Date()).getTime() - requestStart) + myTimeout; This, at least, doesn't seem interesting. I don't think it's worthwhile to add new APIs just so people don't have to do simple math. var now = new Date().getTime(); xhr.timeout = now - requestStart + timeoutLength; This is simple and clean; there's no need to complicate the platform for this. And now writing timers by hand is okay? First, this is a response to the specific point above about clean code, not an argument that using timers this way is necessarily a good idea. Computing a relative timeout delay just isn't complicated. Second, my note to Olli was about using onprogress, not setTimeout. His onprogress example might encounter problems if the UA suspends scripts but not transfers (in order to give predictable battery usage for backgrounded apps). Using setTimeout for completion timeouts might be okay, since the UA would probably also delay timers if it was suspending scripts. The point is, whatever reasons everyone agreed to have timeout, the same reasons apply to dataTimeout. Otherwise they both might as well be dropped. One possible reason--which came to mind writing the above--is that setTimeout delays can be arbitrarily longer than requested. If a UA suspends scripts for ten minutes (eg. the user switches tasks on his phone), and the timeout is setTimeout(f, 60*5), it could result in a 15-minute-long timeout, with the timeout never triggering while backgrounded (so the UA keeps trying unnecessarily). That doesn't automatically means that a data received timeout is needed, though; it still needs use cases. What are our use cases for the request timeout? We can start there and begin a new thread. Likely most of the same use cases apply, only in the context of data (or the lack thereof) being the criteria for firing the timeout as opposed to the overall request time. I would just like to stress that the same reasons (apart from sync requests, some Glenn that you mentioned above) setTimeout doesn't suffice to fully simulate the currently specced request timeout, are also applicable to why scripting progress events w/ the request timeout doesn't suffice to fully simulate the idea of a data timeout. -- Glenn Maynard
[Bug 15306] New: [XHR] (editorial) Mark the event summary section as non-normative.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15306 Summary: [XHR] (editorial) Mark the event summary section as non-normative. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR AssignedTo: ann...@opera.com ReportedBy: kennyl...@csail.mit.edu QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#events Comment: Just like the one for AppCache[1]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#appcacheevents -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15307] New: [XHR] (editorial) the Extensibilty section suggest method prefixing like FooBar() instead of fooBar()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15307 Summary: [XHR] (editorial) the Extensibilty section suggest method prefixing like FooBar() instead of fooBar() Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR AssignedTo: ann...@opera.com ReportedBy: kennyl...@csail.mit.edu QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#extensibility Comment: If I am not missing something, this doesn't match common practice. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[cors] Should browsers send non-user-controllable headers in Access-Control-Request-Headers?
Chrome sends: Access-Control-Request-Headers:Origin, Content-Type, Accept Is that just wrong?
Re: [cors] The case of Http Headers in Access-Control-Request-Headers
On 12/21/11 9:43 PM, Benson Margulies wrote: I just made a small discovery; Chrome 16 sends, e.g. Access-Control-Request-Headers: Content-Type Firefox 8.0 sends, contrastively: Access-Control-Request-Headers: content-type Given the requirement for case-sensitive comparison in the spec Where? http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html section 6.2 step 6 says: If any of the header field-names is not a ASCII case-insensitive match for any of the values in list of headers do not set any additional headers and terminate this set of steps. so the comparison is ASCII case-insensitive. That's as far as server requirements. this to me suggests that one of them is wrong. Which? As far as requirements on the browser go, the relevant part is section 7.1.5 step 1 second list item 2, which says: If author request headers is not empty include an Access-Control-Request-Headers header with as header field value a comma-separated list of the header field names from author request headers in lexicographical order, each converted to ASCII lowercase (even when one or more are a simple header). So what Firefox is doing is correct, and what Chrome is doing is wrong. -Boris
Heads up: RDFa 1.1 headed into Last Call in January 2012
bcc: HTML WG, HTML Data Task Force, Web Apps WG, RDF WG, W3C TAG, SWCG, SVG WG, and PFWG This e-mail is to notify the liaison groups that are listed in the RDF Web Apps Working Group charter that the RDF Web Apps WG will be taking the RDFa 1.1 specs into what it hopes to be their final Last Call in January 2012. If you are so inclined, please take the time to do a review and submit your comments before January 15th 2012, which is the target date for entering Last Call for the RDFa 1.1 Primer, RDFa 1.1 Core, XHTML+RDFa 1.1 and RDFa 1.1 Lite. If it doesn't look like there are any major issues, we'll enter a 3-4 week Last Call period at that time and plan to move swiftly toward REC. Here are the links to the latest specs: RDFa Lite 1.1: http://www.w3.org/TR/2011/WD-rdfa-lite-20111208/ RDFa 1.1 Primer: http://www.w3.org/TR/2011/WD-rdfa-primer-20111208/ RDFa Core 1.1: http://www.w3.org/TR/2011/WD-rdfa-core-20111215/ XHTML+RDFa 1.1: http://www.w3.org/TR/2011/WD-xhtml-rdfa-20111215/ Happy Holidays! :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: The Need for Data-Driven Standards http://manu.sporny.org/2011/data-driven-standards/
Re: [cors] Should browsers send non-user-controllable headers in Access-Control-Request-Headers?
On Wed, Dec 21, 2011 at 9:16 PM, Benson Margulies bimargul...@gmail.comwrote: Chrome sends: Access-Control-Request-Headers:Origin, Content-Type, Accept Is that just wrong? The spec clearly says: author request headers: A list of headers set by authors for the request. Empty, unless explicitly set. So WebKit For me, Chrome 16 sends Origin + all_my_specified_headers, so Chrome is behaving incorrectly. Safari 5.1.2 behaves correctly (though the header list is not lowercased), and Firefox behaves correctly.
[CORS] Allow-Access-Request-Method
The spec makes it very succinct in its preflight request steps that Allow-Access-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are author request headers being sent in Allow-Access-Request-Headers. Is the spec not clear in these steps, or are we all just doing it wrong? :) Thanks, Jarred
[CORS] Access-Control-Request-Method was Re: [CORS] Allow-Access-Request-Method
On Wed, Dec 21, 2011 at 11:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/21/11 11:04 PM, Jarred Nicholls wrote: The spec makes it very succinct in its preflight request steps that Allow-Access-Request-Method should be sent, always. There is no such thing. What header did you actually mean? Access-Control-Request-Method. I'm just tired I guess :) -Boris
[CORS] Access-Control-Request-Method
I'll try this again... The spec makes it very succinct in its preflight request steps that Access-Control-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are author request headers being sent in Access-Control-Request-Headers. Is the spec not clear in these steps, or are we all just doing it wrong? :) Thanks, Jarred
Re: [CORS] Access-Control-Request-Method
On 12/21/11 11:28 PM, Jarred Nicholls wrote: I'll try this again... The spec makes it very succinct in its preflight request steps that Access-Control-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are author request headers being sent in Access-Control-Request-Headers. Is the spec not clear in these steps, or are we all just doing it wrong? :) I'd like to understand your testcase. Looking at the Firefox code for this, Access-Control-Request-Method is always sent when a preflight is done. What might be confusing the issue is that preflights are not always done, maybe? A preflight, per http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request is done in the following cases: 1) The force preflight flag is set. 2) The request method is not a simple method. 3) There is an author request header that's not a simple header. (though it looks to me like item 1 is broken by the actual algorithm for doing a cross-origin request with preflight; Anne?) In any case, if you're using XHR then #1 is likely not relevant, and if you use a GET method then you have a simple method. So the only thing that would trigger preflights are author request headers that are not simple headers. -Boris
Re: [CORS] Access-Control-Request-Method
On Wed, Dec 21, 2011 at 11:37 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/21/11 11:28 PM, Jarred Nicholls wrote: I'll try this again... The spec makes it very succinct in its preflight request steps that Access-Control-Request-Method should be sent, always. However in WebKit and Firefox I'm observing this header only being sent when there are author request headers being sent in Access-Control-Request-**Headers. Is the spec not clear in these steps, or are we all just doing it wrong? :) I'd like to understand your testcase. Looking at the Firefox code for this, Access-Control-Request-Method is always sent when a preflight is done. What might be confusing the issue is that preflights are not always done, maybe? A preflight, per http://dvcs.w3.org/hg/cors/** raw-file/tip/Overview.html#**cross-origin-requesthttp://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-requestis done in the following cases: 1) The force preflight flag is set. 2) The request method is not a simple method. Ack I was using POST but I meant to use PUT. You're all over it, thanks. I'll go to bed now :-p 3) There is an author request header that's not a simple header. (though it looks to me like item 1 is broken by the actual algorithm for doing a cross-origin request with preflight; Anne?) In any case, if you're using XHR then #1 is likely not relevant, and if you use a GET method then you have a simple method. So the only thing that would trigger preflights are author request headers that are not simple headers. -Boris
