Re: [hybi] [whatwg] HttpOnly cookie for WebSocket?

[John Fallows <[e-mail]>]

Agreed.

Kaazing is much more interested in a resolving any outstanding technical
issues with WebSockets rather than the political distractions that seem to
have been hindering real progress.

Regards,
John Fallows

On Thu, Jan 28, 2010 at 2:55 PM, Maciej Stachowiak <[e-mail]> wrote:

>
> +1
>
> We at Apple are interested in moving the technology forward, not so much in
> debating the politics. Can we at least keep procedural mattes out of threads
> about technical questions?
>
>  - Maciej
>
> On Jan 28, 2010, at 2:49 PM, Ian Fette (イアンフェッティ) wrote:
>
> So, moving back to the original question... I am very concerned here. A
> relatively straightforward question was asked, with rationale for the
> question. "May/Should WebSocket use HttpOnly cookie while Handshaking?
> I think it would be useful to use HttpOnly cookie on WebSocket so that we
> could authenticate the WebSocket connection by the auth token cookie which
> might be HttpOnly for security reason."
>
> It seems reasonable to assume that Web Sockets will be used in an
> environment where users are authenticated, and that in many cases the Web
> Socket will be established once the user has logged into a page via
> HTTP/HTTPS. It seems furthermore reasonable to assume that a server may
> track the logged-in-ness of the client using a HttpOnly cookie, and that the
> server-side logic to check whether a user is already logged in could easily
> be leveraged for Web Sockets, since it starts as an HTTP connection that
> includes cookies and is then upgraded. It seems like a very straightforward
> thing to say "Yes, it makes sense to send the HttpOnly cookie for Web Socket
> connections".
>
> Instead, we are bogged down in politics.
>
> How are we to move forward on this spec? We have multiple server
> implementations, there are multiple client implementations, if a simple
> question like this gets bogged down in discussions of WHATWG vs IETF we are
> never going to get anywhere. Clearly there are people on both groups who
> have experience in the area and valuable contributions to add, so how do we
> move forward? Simply telling the folks on WHATWG that they've handed the
> spec off to IETF is **NOT** in line with what I recall at the IETF, where I
> recall agreeing to the two WGs working in concert with each other. What we
> have before us is a very trivial question (IMO) that should receive a quick
> response. Can we use this as a proof of concept that the two groups can work
> together? If so, what are the concrete steps?
>
> If we can't figure out how to move forward on such a simple issue, it seems
> to me that we are in an unworkable situation, and should probably just
> continue the work in WHATWG through to a final spec, let implementations
> settle for a while, and then hand it off to IETF for refinement and
> finalization in a v2 spec... (my $0.02)
>
> -Ian
>
> 2010/1/28 Ian Hickson <[e-mail]>
>
>> On Thu, 28 Jan 2010, Julian Reschke wrote:
>> > Ian Hickson wrote:
>> > > ...
>> > > > The WHATWG submitted the document to the IETF
>> > >
>> > > I don't think that's an accurate portrayal of anything that has
>> occurred,
>> > > unless you mean the way my commit script uploads any changes to the
>> draft to
>> > > the tools.ietf.org scripts. That same script also submits the varous
>> > > documents generated from that same source document to the W3C and
>> WHATWG
>> > > source version control repositories.
>> > > ...
>> >
>> > By submitting an Internet Draft according to BCP 78 you grant the IETF
>> certain
>> > rights; it's not relevant whether it was a script or yourself using a
>> browser
>> > or a MUA who posted it.
>> >
>> > You may want to check <http://tools.ietf.org/html/bcp78#section-5.3>.
>>
>> With the exception of the trademark rights, which I don't have and
>> therefore cannot grant, the rights listed there are a subset of the rights
>> the IETF was already granted by virtue of the WHATWG publishing the spec
>> under a very liberal license. So that doesn't appear to be relevant.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>


-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA