Skip Menu |

This queue is for tickets about the Net-Async-WebSocket CPAN distribution.

Report information
The Basics
Id: 88441
Status: resolved
Priority: 0/
Queue: Net-Async-WebSocket

People
Owner: Nobody in particular
Requestors: jonathan.barber [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.07
Fixed in: 0.12



Subject: Proposed documentation change for Net::Async::WebSocket::Client
I've just got some code based upon Net::Async::WebSocket::Client working against Google's Chrome browser, and I'd like to suggest a change in the documentation which might make it easier for other people to use this module in the future. The problem I encountered was that the form of the send_frame() function given in the synopsis didn't appear to cause any effect on the server. I finally discovered that the send_frame() should include the parameter "masked => 1" and use the named parameter "buffer" to indicate the data to include in the frame. Given this, I'd like to suggest a change in the example client in the SYNOPSIS from: """ $client->connect( host => $HOST, service => $PORT, url => "ws://$HOST:$PORT/", on_connected => sub { $client->send_frame( "Hello, world!\n" ); }, on_connect_error => sub { die "Cannot connect - $_[-1]" }, on_resolve_error => sub { die "Cannot resolve - $_[-1]" }, ); """ to: """ $client->connect( host => $HOST, service => $PORT, url => "ws://$HOST:$PORT/", on_connected => sub { $client->send_frame( masked => 1, buffer => "Hello, world!\n" ); }, on_connect_error => sub { die "Cannot connect - $_[-1]" }, on_resolve_error => sub { die "Cannot resolve - $_[-1]" }, ); """ Cheers
Hmm I see. I must confess I don't really know much about Websockets; I wrote the module mostly under VTI's suggestion as something to integrate with his module. I notice though that the 'masked' parameter doesn't appear to be documented by Protocol::WebSocket::Frame itself. What does it do? Should it be used in this case? -- Paul Evans
Subject: Re: [rt.cpan.org #88441] Proposed documentation change for Net::Async::WebSocket::Client
Date: Thu, 5 Sep 2013 18:17:15 +0100
To: bug-Net-Async-WebSocket [...] rt.cpan.org
From: Jonathan Barber <jonathan.barber [...] gmail.com>
On 5 September 2013 15:56, Paul Evans via RT < bug-Net-Async-WebSocket@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=88441 > > > Hmm I see. I must confess I don't really know much about Websockets; I > wrote the module mostly under VTI's suggestion as something to integrate > with his module. > > I notice though that the 'masked' parameter doesn't appear to be > documented by Protocol::WebSocket::Frame itself. What does it do? Should it > be used in this case? >
I only have 2.5 hours of experience of Websockets myself, so this is probably a case of the blind leading the blind. This comment (by VTI): https://github.com/vti/protocol-websocket/issues/11#issuecomment-7934900 states that "frames from the client to the server [they] should be masked". Parenthetically, I think the reporter of that issue is the same one who reported this issue against Net::Async::WebSocket::Client: https://rt.cpan.org/Public/Bug/Display.html?id=79202 Meanwhile, this blog post: http://www.lenholgate.com/blog/2011/07/websockets---why-do-we-need-to-mask-data-from-client-to-server.html quotes from a working draft of the Websockets RFC that "The client MUST mask all frames sent to the server" because of "security". This is requirement is still present in RFC 6455 and the rational for it is described in section 10.3. From what I understand, the mask is a random value which is used to encode the data sent by the client. This is done to stop badly written proxies (or other network middle devices) from incorrectly parsing this data as HTTP traffic and then acting on it. So, on the basis of these sources I think the client should be masking the frames it sends (unless it is talking to a server speaking an old version of the protocol). -- Jonathan Barber <jonathan.barber@gmail.com>
Subject: Clients should send 'masked' frames
It seems that actually clients ought always be sending masked frames, so that's actually a bug, not just a doc change. -- Paul Evans
Should now be solved with 0.12 -- Paul Evans