Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[John Tamplin]

On Wed, Jul 20, 2011 at 6:54 PM, Adam Barth  wrote:

> Isn't the obvious solution to both problems to apply compression before
> masking?
>

Yes.  However, that is not what deflate-stream does.  There has been a
proposal for deflate-frame which would do exactly that, but it has not been
accepted as of yet and there seems to be some resistance to including it in
the base spec at the expense of further delaying it.

deflate-stream was created as a "better than nothing" compression nobody
objected to that served as an example in the spec of an extension.  Since
then, largely due to your work, masking client->server traffic was added
which reduced the value of deflate-stream in that direction and also
requiring the extension be handled outside the normal framing.

The fact that the WS API would mandate deflate-stream and not allowing
browser to support other extensions would in fact prevent the deployment of
deflate-frame later, or for that matter any other improvements.  I could
hope that browsers would ignore that requirement and support other
extensions, but then the spec isn't reflecting reality.

As a further example, if multiplexing is added later, it may well need to
have compression at a different level (otherwise mux/demux operations have
to decompress and recompress) -- mandating deflate-stream would again
complicate that scenario.

-- 
John A. Tamplin
Software Engineer (GWT), Google

Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[Adam Barth]

On Wed, Jul 20, 2011 at 5:38 PM, Bjoern Hoehrmann  wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann  wrote:
>>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>>> not a solution to the problem Takeshi Yoshino raised though, which is
>>> about whether Websocket API conformance should impose restrictions on
>>> which Websocket extensions must and must not be supported, as far as I
>>> understand it anyway.
>>
>>It seems pretty clear that the API specify whatever profile of the
>>protocol we choose.  We do the same thing with HTTP (e.g., with the
>>XMLHttpRequest API).
>
> HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
> Opera supports that in responses, most other browsers do not. The XML-
> HttpRequest specification takes no position on that, you can conform to
> it whether the XMLHttpRequest implementation supports that or not. The
> browsers do agree on supporting `Content-Encoding: gzip`, but again the
> XMLHttpRequest specification does not require or prohibit supporting it.

XMLHttpRequest imposes restrictions on the HTTP transport that are not
imposed by HTTP itself.  I don't see any reason why an API can't
restrict the protocol elements generated through the use of the API.
You can argue whether we should impose those restrictions, but we
certainly can.

Adam

Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[Bjoern Hoehrmann]

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann  wrote:
>> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
>> not a solution to the problem Takeshi Yoshino raised though, which is
>> about whether Websocket API conformance should impose restrictions on
>> which Websocket extensions must and must not be supported, as far as I
>> understand it anyway.
>
>It seems pretty clear that the API specify whatever profile of the
>protocol we choose.  We do the same thing with HTTP (e.g., with the
>XMLHttpRequest API).

HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
Opera supports that in responses, most other browsers do not. The XML-
HttpRequest specification takes no position on that, you can conform to
it whether the XMLHttpRequest implementation supports that or not. The
browsers do agree on supporting `Content-Encoding: gzip`, but again the
XMLHttpRequest specification does not require or prohibit supporting it.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[Adam Barth]

On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann  wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann  wrote:
>>> The deflate-stream extension, when used for browser to server messages
>>> allows an attacker to put whatever bytes he likes on the wire, after a
>>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>>> for the normal protocol without extensions, and they were opposed to
>>> having some way to make browsers send messages "unmasked"; so it would
>>> be very odd for browser vendors to implement the extension. And by the
>>> looks of it, the hybi Working Group may well drop deflate-stream now.
>>> See 
>>> and .
>>
>>Isn't the obvious solution to both problems to apply compression before 
>>masking?
>
> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
> not a solution to the problem Takeshi Yoshino raised though, which is
> about whether Websocket API conformance should impose restrictions on
> which Websocket extensions must and must not be supported, as far as I
> understand it anyway.

It seems pretty clear that the API specify whatever profile of the
protocol we choose.  We do the same thing with HTTP (e.g., with the
XMLHttpRequest API).

Adam

Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[Bjoern Hoehrmann]

* Adam Barth wrote:
>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann  wrote:
>> The deflate-stream extension, when used for browser to server messages
>> allows an attacker to put whatever bytes he likes on the wire, after a
>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>> for the normal protocol without extensions, and they were opposed to
>> having some way to make browsers send messages "unmasked"; so it would
>> be very odd for browser vendors to implement the extension. And by the
>> looks of it, the hybi Working Group may well drop deflate-stream now.
>> See 
>> and .
>
>Isn't the obvious solution to both problems to apply compression before 
>masking?

There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
not a solution to the problem Takeshi Yoshino raised though, which is
about whether Websocket API conformance should impose restrictions on
which Websocket extensions must and must not be supported, as far as I
understand it anyway.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

[Adam Barth]

On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann  wrote:
> * Takeshi Yoshino wrote:
>>Use of deflate-stream is now mandatory in API spec. I think this kind of
>>requirement is useless. How about leave it up to implementors' decision?
>>http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
>
> The deflate-stream extension, when used for browser to server messages
> allows an attacker to put whatever bytes he likes on the wire, after a
> bit of unpredictable junk. Browser vendors were pretty opposed to that
> for the normal protocol without extensions, and they were opposed to
> having some way to make browsers send messages "unmasked"; so it would
> be very odd for browser vendors to implement the extension. And by the
> looks of it, the hybi Working Group may well drop deflate-stream now.
> See 
> and .

Isn't the obvious solution to both problems to apply compression before masking?

Adam

Re: [whatwg] Specification of window.find()

[Tim Down]

On 20 July 2011 17:58, Aryeh Gregor  wrote:
> On Wed, Jul 20, 2011 at 6:14 AM, Tim Down  wrote:
>> It's useful for custom search features. I've recommended it a few
>> times on Stack Overflow for people wanting to highlight or somehow
>> style all occurrences of a piece of text that may span nodes (it's
>> this part that is the compelling feature). You can achieve the same
>> using TextRange in IE. For example:
>>
>> http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags
>>
>> I think this is a valid use case.
>
> However, the implementation here doesn't do what you'd want: it
> selects the text, destroying any existing selection.  You can work
> around it by preserving and then restoring the selection somehow, but
> it's not ideal at all.

Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.

> It would make much more sense to have a
> function that returned a Range or list of Ranges.

Absolutely.

> Of course, for the use-case you posted, execCommand() would also have
> to work on Ranges instead of just the selection, but that should
> probably be feature #1 to add to it anyway . . .

Agreed. My number two feature (well, it would make the top 5, at
least) would be removing the restriction on execCommand() only working
on editable content. This very use case shows that its usefulness
extends beyond editable content. The temporarily-switch-designMode-on
workaround is ugly, and destroys the selection in some browsers.

Tim

Re: [whatwg] Selectors within

[Kornel Lesiński]

On Wed, 20 Jul 2011 20:55:51 +0100, Ashley Sheridan  
 wrote:




   
 #widget foo {}
   



While I agree that that might be a common pattern, I disagree that it's
actually a good one. Consider an ad service which wraps everything in a
custom  tag. If the scope allowed the immediate parent to be
included as part of the scope, then it could allow the advert to be
altered in a way that could negatively affect the users of the site the
ad appeared on.


The site could wrap the ad in another div to prevent that (and this is  
typical when the site wants to create fixed-size ad slot).



The purpose of scope in the style seems to be to protect elements
outside of the included content and to 'contain' the included content
that has the 

Re: [whatwg] Selectors within

[Ashley Sheridan]

On Wed, 2011-07-20 at 20:36 +0100, Kornel Lesiński wrote:

> On Tue, 19 Jul 2011 05:14:55 +0100, Boris Zbarsky  wrote:
> 
> > This is actually an interesting question.  Does this end up  
> > corresponding to:
> >
> >:scope foo .bar, foo:scope .bar
> >
> > or to just
> >
> >:scope foo .bar
> >
> > ?  The latter would not match on 'foo' being the scope element, while  
> > the former would.
> 
> I think it should match the scoping element, as I expect this pattern to  
> be common until  is widely supported:
> 
> 

>