Re: [cors] Content-Type
On Wed, 22 Jun 2011 14:44:44 +0200, Anne van Kesteren ann...@opera.com wrote: There is one other problem noted by sicking on the WHATWG list. Namely that Content-Type can also be set by the user agent. E.g. based on the File object passed to the send() method in XMLHttpRequest. So I think I will update the places where CORS compares author request headers (I renamed custom request headers as author is clearer and custom caused confusion) against simple headers to also compare the Content-Type header (if set by the user agent) against simple headers. Just to follow up on this (again) in case anyone missed it. This was solved by changing XMLHttpRequest's send() method to append Content-Type to author request headers (if not there already) based on File/DOMString/etc., rather than set Content-Type directly outside of the context of author request headers. Any API interacting with CORS with a request Content-Type header will have to include it in its author request headers as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote: Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). Who's in charge of updating TLS? Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
TL;DR: JC and Leonard are right. Pointing to a moving target makes any statement about conformance pretty much unusable in the real world. Which is significantly worse than having a statement of conformance to something known to contain errors and bugs. 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. 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. A lack of stability and precision about which version of a specification is meant also makes it harder to get a decent royalty-free license. Details below... On Mon, 19 Dec 2011 14:03:58 +0100, Marcos Caceres w...@marcosc.com wrote: I'm sorry, but Leonard is not correct: this is the W3C, not ISO. Yes, so far so good... ISO is a real standards body (i.e., can be legally binding for governments). W3C is a business/community consortium (i.e., not a legal standards body and specs are not legally binding): W3C makes recommendations, which are not (and should not be) legally binding. So what? In practice, people make contracts (legally binding documents) that include such terms as conformance to In ISO specs, undated references are forbidden. There is a team of people (called ITTF) whose job includes checking these things and bugging spec editors to fix them. Yes, but this is not ISO. And just because they operate in that manner, it also doesn't mean that ISO is right. True, but it also doesn't mean they are wrong. There is such a thing as certification. It is impossible to do if the spec is not fixed, including references. What if there is a bug in the spec? or a test is wrong and it's fixed after someone has claimed compliance? This happens all the time, and has done for decades. Wat happens is tha by dating explicit versions, you can deal with a known state. Something that conforms to the earlier, buggy version, or to the later better (but almost certainly not bug-free, as you seem to freely acknowledge) version, have a set of known properties. This is helpful when you are trying to include them as *parts* of an ecosystem. What you are advocating is entirely counterproductive given the source of the discussion (= a PAG): if the spec has undated references, you cannot make sure it is royaltee-free. Yes you can: the /latest/ always points to the latest REC. REC is royalty free. No, that is not guaranteed. Under the current process any substantive change between last call and Recommendation means, as far as I can tell from carefully reading what gets licensed, that the change cannot be assumed to be covered by the patent license unless it happened to be in the first public working draft. Even in that situation I can see a legal argument that the technology is not covered by any license. And of course *until* Recommendation, there is no license. If the scope of one reference changes, there is a new risk. It is not only a problem of conformance testing. Not if the /latest/ always points to a REC (or a periodical snapshot where IPR commitments to RF have been made). If you always ensure you are pointing to a particular version of reference, over which you guarantee that a commitment has been made, then you are correct. I haven't heard that condition even suggested (let alone specified in a practical manner) for any living standard before. Your vision of fluid standards is completely unmanageable in practice. Yet, somehow, every browser vendor manages? Seems like an enigma. Actually, I dispute that *any* browser vendor has achieved this. After years of effort and refinement, most browsers have pretty good coverage of CSS 2.1 - precisely because it stopped being a living standard and became a stable target. On the contrary, anyone who claims they conform to HTML5 is either stupid, since that is a meannigless claim while the definition of HTML5 is known to be in flux, or thinks we are stupid enough to believe it. I don't believe any browser makes, nor could make without being laughed at, such a claim. What browser vendors do is implement pieces of what they think HTML5 will be, changing them as the spec changes in an effort to find emergent patterns from what other browser developers, content producers with big enough market share to insist on people doing what they want, and hope (forlornly in many cases) that the developers who relied on what happened before will actually change their code, so the browser can minimise the multiple
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote: Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my response. With that said, this isn't TLS 1.1, but rather a specific, more backwards-compatible countermeasure. It's fine for the security considerations section to say here that browsers must do either TLS 1.1 or 1/n+1 splitting, but it should say something, since it's not like 1/n+1 splitting is required by TLS (any version). Who's in charge of updating TLS? Me. Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. -Ekr
Re: [XHR] chunked requests
On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote: On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. If support for the old version cannot be removed it does not seem to me that the problem is actually addressed as far as user agents that have to support legacy servers are concerned. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote: On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote: Surely this should be patched in the base specification rather than in every API that interacts with it. I do not want to make the life of the guy implementing XMLHttpRequest more difficult if the problem is supposed to be addressed at the TLS layer anyway. The problem was addressed at the TLS layer 5 years ago when we issued TLS 1.1. If support for the old version cannot be removed it does not seem to me that the problem is actually addressed as far as user agents that have to support legacy servers are concerned. I see your point, but it's not clear what you would like done about it. The TLS WG specifies protocols, not APIs, and this is an API issue. Even if it were within scope, all we would do is add some sort of security considerations note to the TLS spec, but again, it would only apply to RFC 2246, since TLS 1.1 and 1.2 don't have this problem. That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. -Ekr
Re: [XHR] chunked requests
On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote: That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. What I would like is a standard that actually defines what of TLS user agents need to implement. Instead of every user agent having to figure that out for themselves. Those unknowns (TLS is not alone here) create a barrier to entry and make it harder to create user agents that interoperate with legacy content. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
On Tue, Dec 20, 2011 at 2:47 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote: That isn't to say that the browser stacks aren't adding 1/n+1 splitting. NSS, for instance, has such a fix. However, I don't think there's anything to do from a TLS standards perspective. What I would like is a standard that actually defines what of TLS user agents need to implement. Instead of every user agent having to figure that out for themselves. Those unknowns (TLS is not alone here) create a barrier to entry and make it harder to create user agents that interoperate with legacy content. Again, the TLS spec does tell you what to do: it tells you to implement TLS 1.1 and/or 1.2. What you're asking for is for it *also* to tell you what to do in cases where you choose to use a downrev version of TLS. But unfortunately, that guidance is necessarily application specific. In particular, the use of 1/n+1 splitting is the result of discovering that some HTTP stacks don't properly handle empty TLS records and even then some stacks choke Moreover, many non-HTTPS stacks have no need to do any sort of countermeasure because Rizzo-Duong-style attacks don't apply. If/when IETF publishes a revision of TLS, I suspect we'll add a description of 1/n+1 splitting as a backward compatibility measure, but I don't really think it's the role of standards to document security hacks for downrev versions in perpetuity. -Ekr
[webcomponents]: First draft of the Shadow DOM Specification
Happy Holidays! 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 It's not quite a Christmas miracle, more like that extra unlabeled gift box you found in the drapes while breaking down the tree. Perhaps uncle Herman forgot to use proper glue. Or maybe it's from Santa. Who knows. Please feel encouraged to use your holiday downtime to look over the spec and file bugs. 3 XOXO 3 :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
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: [webcomponents]: First draft of the Shadow DOM Specification
On 12/20/11 4:49 PM, Edward O'Connor wrote: #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. Would you expand more on that non-shadow-DOM-specific idea? In the meantime, I'm happy with the ::shadow(controls) selector.
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Tue, Dec 20, 2011 at 4:49 PM, Edward O'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 Oooh, good catch. I actually haven't specified a method for addressing shadow DOM elements in the subtree yet. That's bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15196 (or thereabouts). I need to rewrite the example to not use that plumbing (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15288). 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) Yes, I like that. Need to talk with the CSS people and get this done. There are also CSS Variables that could fit into this shape. 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! You're welcome! And everyone, please note that reading this spec is an excellent excuse for hiding from your in-laws or getting out of that annual Mall of America family shopping marathon. :DG Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
Re: [webcomponents]: First draft of the Shadow DOM Specification
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? 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? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... -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
[Bug 15292] New: HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15292 Summary: HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket-Protocol: sample 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 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket-Protocol: sample 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.
