Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
Is new XHR spec going to make gzip mandatory for its underlying HTTP? On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor simetrical+...@gmail.comwrote: From the discussion here, it sounds like there are problems with WebSockets compression as currently defined. If that's the case, it might be better for the IETF to just drop it from the protocol for now and leave it for a future version, but that's up to them. As far as we're concerned, if the option is really a bad idea to start with, it might make sense for us to prohibit it rather than require it, but there's no reason at all we have to leave it optional for web browsers just because it's optional for other WebSockets implementations. Regarding deflate-stream, I think prohibiting is better than requiring. But I still don't understand the benefit of banning any extension other than what specified in the API spec. There are two different assertions made by W3C side. (a) it's not acceptable to make support (== request) of good-compression optional (b) it's not acceptable to allow any other compression/extension than specified in the API spec (a) is supported by the discussion you and Anne made by using analogy with HTTP. I may agree with this. (b) is what Hixie was asserting in the bug entry. I'd like to see clear support for (b). No one knows what kind of compression will be finally the win for WebSocket. I'd like to see ideas about how the evolution of WebSocket will be like. With (b), to experimentally implement some extension/compression not specified in the API spec, we have to make our browser non-compliant with W3C spec. I'd suggest that, once better-deflate is ready by IETF, W3C uses text like the user agent MUST request better-deflate extension instead of JUST better-deflate extension. Thanks, Takeshi
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com wrote: Is new XHR spec going to make gzip mandatory for its underlying HTTP? I do not think that analogy makes sense. The WebSocket protocol can only be used through the WebSocket API, HTTP is prevalent in more places. Having said that, XMLHttpRequest does place constraints on HTTP. E.g. it requires redirects to be followed, it does not expose 1xx responses, only works cross-origin in combination with CORS, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com wrote: Is new XHR spec going to make gzip mandatory for its underlying HTTP? I do not think that analogy makes sense. The WebSocket protocol can only be used through the WebSocket API, HTTP is prevalent in more places. What do you mean by more places? Having said that, XMLHttpRequest does place constraints on HTTP. E.g. it requires redirects to be followed, it does not expose 1xx responses, only works cross-origin in combination with CORS, etc. I agree that there're some constrains must be placed on underlying protocol to make it useful/secure on browser.
[CORS] Does Origin have to be included in the Access-Control-Request-Headers field?
Hi guys, I'm the maintainer of CORS Filter, a small library for retrofitting Java web apps with CORS support. A developer who is using the library reported that the library was unexpectedly denying CORS requests from version 13 (still in beta) Google Chrome browsers. He contacted Google support and was informed that Chrome 13 is including Origin in the Access-Control-Request-Headers field. Is this browser behaviour proper according to the CORS protocol? My understanding of the CORS spec is that Access-Control-Request-Headers is meant only for custom headers appended to the XHR request by means of its setRequestHeader method. Is this so? My tests have also shown that FF, Safari, IE and also Chrome (up to version 12) do not include Origin in the Access-Control-Request-Headers header of outgoing CORS requests. Greetings, Vladimir -- Vladimir Dzhuvinov :: vladi...@dzhuvinov.com http://NimbusDS.com :: Nimble directory services for web and cloud applications
Re: [CORS] Does Origin have to be included in the Access-Control-Request-Headers field?
On Wed, Jul 27, 2011 at 9:32 AM, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: Hi guys, I'm the maintainer of CORS Filter, a small library for retrofitting Java web apps with CORS support. A developer who is using the library reported that the library was unexpectedly denying CORS requests from version 13 (still in beta) Google Chrome browsers. He contacted Google support and was informed that Chrome 13 is including Origin in the Access-Control-Request-Headers field. Is this browser behaviour proper according to the CORS protocol? My understanding of the CORS spec is that Access-Control-Request-Headers is meant only for custom headers appended to the XHR request by means of its setRequestHeader method. Is this so? My tests have also shown that FF, Safari, IE and also Chrome (up to version 12) do not include Origin in the Access-Control-Request-Headers header of outgoing CORS requests. Your understanding is correct. Similarly headers such as User-Agent, Host and Referer aren't listed in Access-Control-Request-Headers. Nor is the Access-Control-Request-Headers header itself. We recently clarified this in the CORS spec as I recall it. / Jonas
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com wrote: What do you mean by more places? XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc. So indicating what parts of the HTTP protocol are mandatory for browsers is not really in scope for XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
[Reminder]: Last Call Working Drafts transition announcement of the API for Media Resources 1.0
Le 12/07/2011 20:00, Thierry MICHEL a écrit : Chairs and Team Contact, (1) This is a 2nd Last Call Working Draft Transition Announcement for the following Recommendation Track specification: (2) Document Title and URI * API for Media Resources 1.0 http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/ (3) Instructions for providing feedback If you wish to make comments regarding this specification please send them to public-media-annotat...@w3.org which is an email list publicly archived at http://lists.w3.org/Archives/Public/public-media-annotation/ Please use [2ndLC Comment API] in the subject line of your email. (4) Review end date The Last Call period ends on 07 August 2011. (5) A reference to the group's decision to make this Transition The Media Annotations Working Group made the decision for this Transition at its teleconference on July 5th 2011: Resolution: the wg agrees to move the api doc to 2nd LC http://www.w3.org/2011/07/05-mediaann-minutes.html (6) Evidence that the document satisfies group's requirements. Include a link to requirements The Media Annotations Working Group believes that these specifications satisfy the requirements of the working group's charter at http://www.w3.org/2008/01/media-annotations-wg.html and the Use Cases and Requirements for Ontology and API for Media Resource 1.0 at http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/ (7) The names of groups with dependencies, explicitly inviting review from them. The following groups are known or suspected to have dependencies on this specification: * Semantic Web Deployment Working Group * Semantic Web Coordination Group * Scalable Vector Graphics Working Group (SVG) * Web Applications (WebApps) Working Group * HyperText Markup Language (HTML) Working Group * The Device API and Policy (DAP) Working Group also the following groups have liaisons on one or more of these specifications: * Protocol for Web Description Resources (POWDER) Working Group * Protocols and Formats Working Group The Media Annotations Working Group requests review from each of these working groups. The chairs of the working group listed have been copied on the distribution list of this transition announcement as well as other individuals known to have expressed prior interest. (8) Report of any Formal Objections The Working Group received no Formal Objection during the preparation of this specification. (9) Patent Disclosure Page Link can be found at http://www.w3.org/2004/01/pp-impl/42786/status This Transition Announcement has been prepared according to the guidelines concerning such announcements at http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.htmlxslfile=http://www.w3.org/2005/08/transitions.xsldocstatus=lc-wd-tr#trans-annc Regards, Thierry Michel (on behalf of the Media Annotations Working Group chairs) Team Contact for the Media Annotations WG.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com wrote: What do you mean by more places? XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc. So indicating what parts of the HTTP protocol are mandatory for browsers is not really in scope for XMLHttpRequest. So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//.
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//* *. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5// **. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [CORS] Does Origin have to be included in the Access-Control-Request-Headers field?
On 27 July 2011 17:44, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 27, 2011 at 9:32 AM, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: Hi guys, I'm the maintainer of CORS Filter, a small library for retrofitting Java web apps with CORS support. A developer who is using the library reported that the library was unexpectedly denying CORS requests from version 13 (still in beta) Google Chrome browsers. He contacted Google support and was informed that Chrome 13 is including Origin in the Access-Control-Request-Headers field. Is this browser behaviour proper according to the CORS protocol? My understanding of the CORS spec is that Access-Control-Request-Headers is meant only for custom headers appended to the XHR request by means of its setRequestHeader method. Is this so? My tests have also shown that FF, Safari, IE and also Chrome (up to version 12) do not include Origin in the Access-Control-Request-Headers header of outgoing CORS requests. Your understanding is correct. Similarly headers such as User-Agent, Host and Referer aren't listed in Access-Control-Request-Headers. Nor is the Access-Control-Request-Headers header itself. We recently clarified this in the CORS spec as I recall it. Thank you Jonas for setting this straight. I carefully examined the bits of the CORS spec (edition http://www.w3.org/TR/2010/WD-cors-20100727/ ) relevant to the Access-Control-Request-Header. Those who understand the case for CORS and what led to its development will probably have no problem getting the intended meaning of this header. However, to a programmer who is rushing to implement CORS and is following the spec by the word this may not be so obvious. My suggestion is to add a few lines to section 4.9 to be more explicit on the actual intent of the Access-Control-Request-Header so others don't do a similar mistake again. As for Google, I hope the guys at Chrome will be able to rectify their mistake before version 13 is officially shipped. Cheers, Vladimir -- Vladimir Dzhuvinov :: vladi...@dzhuvinov.com http://NimbusDS.com :: Nimble directory services for web and cloud applications
Re: [CORS] Does Origin have to be included in the Access-Control-Request-Headers field?
On Wed, 27 Jul 2011 14:19:26 -0700, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: I carefully examined the bits of the CORS spec (edition http://www.w3.org/TR/2010/WD-cors-20100727/ ) relevant to the Access-Control-Request-Header. Could you please review http://dev.w3.org/2006/waf/access-control/ instead? The TR/ version is (always) out of date. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
I don't think we want to forbid any extensions. The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5/ /**. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: I don't think we want to forbid any extensions. At the protocol level, sure. At the API level we have to pick which functionality user agents are required to support and which they are required not to support, having 'optional' stuff is not an option. It sounds like you are saying that deflate-stream is bad, so we should not have it in the API. - James The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5/ /**. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote: I don't think we want to forbid any extensions. At the protocol level, sure. At the API level we have to pick which functionality user agents are required to support and which they are required not to support, having 'optional' stuff is not an option. It sounds like you are saying that deflate-stream is bad, so we should not have it in the API. - James The whole point of extensions is to allow people to do something that doesn't necessarily have consensus by a broad enough group to be in the base protocol. That said, I think a lot of people would be happier if deflate-stream were an independent document as opposed to being the only extension included in the core specification as a known extension. -Ian 2011/7/27 James Robinson jam...@google.com On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.com wrote: We are talking about it at IETF81 this week. That said, I think either way browsers should not require deflate-stream. I am hoping we can make forward progress on deflate-application-data ( http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01). If we can get that through the process I could live with Chrome being required to support that. As for the protocol doc, the protocol lists deflate-stream as an example, not a requirement, so the mere fact that I don't want to support that particular extension isn't necessarily the strongest argument for taking it out of the protocol as the protocol doesn't require that it be supported. The API should not require the support of that particular extension either, as that extension is particularly bad. Sounds like the consensus is to forbid this extension at the API layer, then. - James -Ian On Wed, Jul 27, 2011 at 11:11 AM, Anne van Kesteren ann...@opera.comwrote: On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com wrote: So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//**. HTML5 is mostly transport-layer agnostic. I am not sure why we are going through this theoretical side-quest on where we should state what browsers are required to implement from HTTP to function. The HTTP protocol has its own set of problems and this is all largely orthogonal to what we should do with the WebSocket protocol and API. If you do not think this particular extension makes sense raise it as a last call issue with the WebSocket protocol and ask for the API to require implementations to not support it. Lets not meta-argue about this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011 15:31:28 -0700, Ian Fette (イアンフェッティ) ife...@google.com wrote: I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. The API specification is not frozen. Case in point: http://html5.org/r/6330 -- Anne van Kesteren http://annevankesteren.nl/
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On Wed, 27 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: I agree we shouldn't require deflate-stream it in the API. I don't agree the API should specify an exact set of extensions, as that would prevent any future versions/developments. A minimum baseline would be reasonable though, once we have that minimum baseline in place (e.g. a stable set of extensions that are well tested, such as compression and multiplexing). I don't think we should put the cart before the horse. As soon as there's a feature that browsers are to implement, we would update the WebSockets spec to list it as a requirement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)
On 27 July 2011 20:35, Takeshi Yoshino tyosh...@google.com wrote: (a) it's not acceptable to make support (== request) of good-compression optional I understand the desire to make good compression universal, but I'm not sure that making it a required part of the specification is the way to go. (b) it's not acceptable to allow any other compression/extension than specified in the API spec So long as the selection of extensions is essentially transparent to the application using the API, then the implementation should be free to use extensions. If a mux extension is developed that either includes it's own compression or works better with some alternative compression, then we don't want to stop browsers from adopting that extension because it would mean that they are non compliant with the API specification. So isn't there a compromise, of coming up with words that express that browsers SHOULD implement and some set of extensions, but allow user-agents to use other extensions without being called non compliant. regards
RE: From-Origin FPWD
-Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Friday, July 22, 2011 8:09 AM To: WebApps WG Subject: From-Origin FPWD Hi, The WebApps WG published the From-Origin header proposal as FPWD: http://www.w3.org/TR/from-origin/ The main open issue is whether X-Frame-Options should be replaced by this header or should absorb its functionality somehow. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: HTTP, websockets, and redirects
On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro gabriel.montene...@microsoft.com wrote: Thanks Adam, By discussed on some mailing list, do you mean a *W3C* mailing list? A quick search turned up this message: But I'm totally fine with punting on this for the future and just disallowing redirects on an API level for now. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079.html I started that thread at Greg Wilkins' recommendation: This is essentially an API issue for the browser websocket object. http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html Also, allowing the users to handle these explicitly implies that the API does not mandate dropping the connection. Currently, the API does not have this flexibility, nor does it allow other uses of non-101 codes, like for authentication. I understand the potential risks with redirects in browsers, and I thought at one moment we were going to augment the security considerations with your help for additional guidance. If websec has already worked on similar language in some draft that we could reuse that would be great, or, similarly, if we could work with you on that text. We can always add support for explicitly following redirects in the future. If we were to automatically follow them today, we'd never be able to remove that behavior by default. Adam -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Sunday, July 24, 2011 13:35 To: Thomas Roessler Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald Alvestrand; Tobias Gondrom Subject: Re: HTTP, websockets, and redirects This issue was discussed on some mailing list a while back (I forget which). The consensus seemed to be that redirects are the source of a large number of security vulnerabilities in HTTP and we'd like users of the WebSocket API to handle them explicitly. I'm not sure I understand your question regarding WebRTC, but the general answer to that class of questions is that WebRTC relies, in large part, on ICE to be secure against cross-protocol and voicehammer attacks. Adam On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roessler t...@w3.org wrote: The hybi WG is concerned about the following clause in the websocket API spec: When the user agent validates the server's response during the establish a WebSocket connection algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection. http://dev.w3.org/html5/websockets/ Discussion with the WG chairs: - this looks like a conservative attempt to lock down redirects in the face of ill-understood cross-protocol interactions - critical path for addressing includes analysis of interaction with XHR, XHR2, CORS - following redirects in HTTP is optional for the client, therefore in principle a decision that a client-side spec can profile - concern about ability to use HTTP fully before 101 succeeds, and future extensibility Salvatore and Gabriel will bring this up later in the week with websec, and we'll probably want to make it a discussion with Webappsec, too. Side note: Does WebRTC have related issues concerning multiple protocols in a single-origin context? Are there lessons to learn from them, or is the case sufficiently different that we need a specific analysis here? Thanks,
RE: From-Origin FPWD
I'm still not convinced that implementing this as a feature of the User Agent benefits the user or is the most appropriate technology for addressing the problem statements in the specification. What are the use cases where a user is better off if their browser obeys From-Origin than if it does not? Bandwidth theft? The user wants to see the image. The problem, such that one exists, is for the hosting server. They can and do address this risk with the Referrer header today. Servers are not better off with this mechanism, since From-Origin is enforced too late, on the client-side, after they've already paid the bandwidth cost to send the image. Font licensing? Again, the user would prefer that his or her agent display the font. The license here is about attempting to keep the user from using something of value and their own agent is a poor policy enforcement point for this. Clickjacking? X-Frame-Options has support in every major browser and is currently sent by over 10,000 sites according to http://www.shodanhq.com/. I see little reason to re-invent something with such broad adoption, or to conflate a feature that is scoped to provide clear security benefit with additional features that users are incentivized to disable. (client-side license and bandwidth theft enforcement) Privacy leakage? Elimination of side channels is an extremely difficult task; generally the best result is that the bandwidth of such channels can be limited, but we are attempting to protect a single bit of information here. Methods such as cache-timing and the active attacks recently described by Weinberg, et al (http://websec.sv.cmu.edu/visited/visited.pdf) are likely more than sufficient to reveal whether a user has an account somewhere. Do we have any data here on how common this very specific kind of leakage is, and if there are any sites that would actually be interested in sending this header for this purpose? For this specific case, I would again assert that server-side enforcement based on Referer is simpler and more likely to succeed, as the server can send the same response for both conditions to unauthorized parties, instead of sending a differential response anyway and asking that it not be measured. -Brad P.S: the header itself is a cause of privacy leakage for the sending server by indicating which other servers it is willing to allow embedding content in. There are also issues of header size with the proposed approach. In X-Frame-Options, the current discussion is to allow only a single origin instead of a list. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Friday, July 22, 2011 8:09 AM To: WebApps WG Subject: From-Origin FPWD Hi, The WebApps WG published the From-Origin header proposal as FPWD: http://www.w3.org/TR/from-origin/ The main open issue is whether X-Frame-Options should be replaced by this header or should absorb its functionality somehow. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
[Bug 13162] The notes really do need to be cleaned up to be made explicit. Like WTH does this actually say? The fail the WebSocket connection algorithm invokes the close the WebSocket connection a
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13162 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-07-28 01:27:05 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: style change Rationale: I adjusted the styles as suggested in comment 1. Changing the names of the algorithms doesn't work since they're defined in the protocol spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
