Re: [hybi] Extensibility mechanisms?

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> On Wed, Jul 21, 2010 at 9:14 PM, Scott Ferguson <[e-mail]> wrote:
>   
>> Adam Barth wrote:
>>     
>> I see only 3 possible resolutions:
>>
>>  a) That 1 & 2 are irreconcilable and WebSocket performance must be worse
>> than HTTP/comet because its security must be better than HTTP.
>>     
>
> I don't understand what this means.  How could latency requirements
> for a network protocol be irreconcilable with cross-site scripting?
> The two operate at completely different layers of abstraction.
>   
I meant cross-protocol, of course.

The issue is the number of request/response before the initial payload 
is sent. If we require the client to wait to validate the server before 
it can send its payload, the initial performance will be slower than a 
HTTP POST.

That delay may be perfectly acceptable, but some people have raised it 
as an issue in the group. I'm fine with the delay myself, but I think it 
should be resolved.
>>  b) WebSocket performance must be as good as HTTP/comet as long as its
>> security is no worse than HTTP.
>>     
>
> What does it mean for security to be no worse than HTTP?  
Specifically, the fundamental issue with sending data before the server 
is validated by the client, like HTTP POST.

Is that capability acceptable for WebSockets or not? (I mean in any 
form, my specific proposal is irrelevant.)
> I've already did so back in May:
>
> http://www.ietf.org/mail-archive/web/hybi/current/msg01948.html
>
> This is different from the protocol in the current working draft
> because it requires TLS.  I think TLS+NPN is a much better design than
> the current HTTP-ish design, for the reasons outlined in that email.
> The main (only?) disadvantage is that it requires amateur server
> implementations to use a TLS library.
>   
Well, yes, that certainly addresses the security issue. The open 
question is whether that's acceptable performance-wise. If it is 
acceptable, fine, we're done. (There is the secondary issue of NPN being 
a draft which is an issue with libraries being available in the near term.)
> It's fine to propose designs as food for thought, but claiming that
> you've addressed all the requirements when you haven't even met the
> basic security requirements is a bit brash.
>   
True, and I apologize for that. I was thinking of the binary framing 
requirements that are ignored by the current spec (and are claimed to be 
too complicated), not the handshake requirements that are already 
addressed. I only added the handshake to the draft for completeness 
sake, not because it adds anything new.

-- Scott