hey, the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not delivered to handler as payload ? <pre> Example WS Request GET /demo HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Sec-WebSocket-Protocol: sample Upgrade: WebSocket Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 Origin: http://example.com ^n:ds[4U </pre> could we get that somehow ...
On Mon, Nov 01, 2010 at 03:50:58PM +0100, Peter Fagerlund wrote: > hey, > > the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not > delivered to handler as payload ? > GET /demo HTTP/1.1 > Host: example.com > Connection: Upgrade > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 > Sec-WebSocket-Protocol: sample > Upgrade: WebSocket > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 > Origin: http://example.com No content-length? Is this a normal websockets request? If so then that's super screwed up. Either way you should be getting this data as the body of the request. I'm pretty sure mongrel2 will just read it and send it, although there's other things that won't work so well until I put the gear in for it. Stay tuned, I may work on this later tonight and get WebSockets in. -- Zed A. Shaw http://zedshaw.com/
ry at nodejs has in his http-parser taken into account the upgrade of http :
<pre>
The Special Problem of Upgrade
------------------------------
HTTP supports upgrading the connection to a different protocol. An
increasingly common example of this is the Web Socket protocol which sends
a request like
GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample
followed by non-HTTP data.
(See http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 for more
information the Web Socket protocol.)
To support this, the parser will treat this as a normal HTTP message without
a
body. Issuing both on_headers_complete and on_message_complete callbacks.
However
http_parser_execute() will stop parsing at the end of the headers and
return.
The user is expected to check if `parser->upgrade` has been set to 1 after
`http_parser_execute()` returns. Non-HTTP data begins at the buffer supplied
offset by the return value of `http_parser_execute()`.
</pre>
On Mon, Nov 1, 2010 at 9:05 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Mon, Nov 01, 2010 at 03:50:58PM +0100, Peter Fagerlund wrote:
> > hey,
> >
> > the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not
> > delivered to handler as payload ?
>
> > GET /demo HTTP/1.1
> > Host: example.com
> > Connection: Upgrade
> > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
> > Sec-WebSocket-Protocol: sample
> > Upgrade: WebSocket
> > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
> > Origin: http://example.com
>
>
> No content-length? Is this a normal websockets request? If so then
> that's super screwed up.
>
> Either way you should be getting this data as the body of the request.
> I'm pretty sure mongrel2 will just read it and send it, although there's
> other things that won't work so well until I put the gear in for it.
>
> Stay tuned, I may work on this later tonight and get WebSockets in.
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
ohhh and 76 is the proto to target i guess http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 On Tue, Nov 2, 2010 at 6:51 AM, Peter Fagerlund <admin@iprobot.com> wrote: > ry at nodejs has in his http-parser taken into account the upgrade of http > : > > <pre> > > The Special Problem of Upgrade > ------------------------------ > > HTTP supports upgrading the connection to a different protocol. An > increasingly common example of this is the Web Socket protocol which sends > a request like > > GET /demo HTTP/1.1 > Upgrade: WebSocket > Connection: Upgrade > Host: example.com > Origin: http://example.com > WebSocket-Protocol: sample > > followed by non-HTTP data. > > (See http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75 for > more > information the Web Socket protocol.) > > To support this, the parser will treat this as a normal HTTP message > without a > body. Issuing both on_headers_complete and on_message_complete callbacks. > However > http_parser_execute() will stop parsing at the end of the headers and > return. > > The user is expected to check if `parser->upgrade` has been set to 1 after > `http_parser_execute()` returns. Non-HTTP data begins at the buffer > supplied > offset by the return value of `http_parser_execute()`. > > </pre> > > On Mon, Nov 1, 2010 at 9:05 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > >> On Mon, Nov 01, 2010 at 03:50:58PM +0100, Peter Fagerlund wrote: >> > hey, >> > >> > the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not >> > delivered to handler as payload ? >> >> > GET /demo HTTP/1.1 >> > Host: example.com >> > Connection: Upgrade >> > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 >> > Sec-WebSocket-Protocol: sample >> > Upgrade: WebSocket >> > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 >> > Origin: http://example.com >> >> >> No content-length? Is this a normal websockets request? If so then >> that's super screwed up. >> >> Either way you should be getting this data as the body of the request. >> I'm pretty sure mongrel2 will just read it and send it, although there's >> other things that won't work so well until I put the gear in for it. >> >> Stay tuned, I may work on this later tonight and get WebSockets in. >> >> -- >> Zed A. Shaw >> http://zedshaw.com/ >> > >
On Tue, Nov 02, 2010 at 06:52:51AM +0100, Peter Fagerlund wrote: > ohhh and 76 is the proto to target i guess > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 That protocol is absolutely horrible. It's easy to support, but for my own sanity I've gotta write about how stupid it is before I do. -- Zed A. Shaw http://zedshaw.com/
yes very good We should . that means You in this case, write about it and propose a better one in a RFC ... meanwhile all i need is for m2 to slap on the payload with length to handler ... if parser encounter a http upgrade request and leave it up to the handler to act upon it ... anyway alot of fun stuff can be had with ws ... this is a window open for making clear that in one POV M2 is just you router connector to LA APPS. And its first in bridging zmq to/from* HTTP and WS to zmq ... i think many se M2 as a webserver when in fact i view it as a HTTP frontend to any DIR, PROXY, zmq_HANDLER domain ... at zmq list they now discuss the security model that can be had with zmq : Pieter Hintjens write : <pre> The options seem to be: * Use a VPN (horrid, for most people except network admins who like this) * Use per-message encryption (as PyZMQ does but it leaves the question of key exchange unsolved) * Use TLS/SSL as a transport (seems cleanest but is incompatible with multicast and the notion of hops over devices) * Tunnel over a secure protocol, e.g. HTTPS (should be interesting, especially to make 0MQ accessible to web applications) </pre> the last one there Tunnel over HTTPS = M2 in your zmq toolbox ... *(to/from*) we need a client call from handler to M2 making client HTTP requests ? ... On Tue, Nov 2, 2010 at 10:16 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > > On Tue, Nov 02, 2010 at 06:52:51AM +0100, Peter Fagerlund wrote: > > ohhh and 76 is the proto to target i guess > > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 > > That protocol is absolutely horrible. It's easy to support, but for my > own sanity I've gotta write about how stupid it is before I do. > > -- > Zed A. Shaw > http://zedshaw.com/
Regular api or Go HTTP api? If you can send me a copy of the incoming m2 message I can write a test case pretty easily. Jim On Nov 1, 2010, at 7:50 AM, Peter Fagerlund wrote: > hey, > > the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not delivered to handler as payload ? > > <pre> Example WS Request > > GET /demo HTTP/1.1 > Host: example.com > Connection: Upgrade > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 > Sec-WebSocket-Protocol: sample > Upgrade: WebSocket > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 > Origin: http://example.com > > ^n:ds[4U > > </pre> > > could we get that somehow ...
Raw Request :
F09D359F-2A7C-45C9-9311-7ED4D57555AE 2 /chatjs
457:{"PATH":"/chatjs","host":"127.0.0.1:1234","sec-websocket-key1":"2 [D]
jl53L 36F 319~ Hn
yt0","cookie":"__utma=96992031.97395809.1287150793.1287150793.1287150793.1;
__utmz=96992031.1287150793.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)","origin":"file://","x-forwarded-for":"0.0.0.0","upgrade":"WebSocket","connection":"Upgrade","sec-websocket-key2":"1
9 848 4d 1 79
6","METHOD":"GET","VERSION":"HTTP/1.1","URI":"/chatjs","PATTERN":"/chatjs"},0:,
thats whats comming in to handler from m2 from a moo-ws js html page request
...
whats "Regular api or Go HTTP api?" ? ...
best r
On Mon, Nov 1, 2010 at 7:03 PM, Jim McGrath <jimmc2@gmail.com> wrote:
> Regular api or Go HTTP api?
>
> If you can send me a copy of the incoming m2 message I can write a test
> case pretty easily.
>
> Jim
>
> On Nov 1, 2010, at 7:50 AM, Peter Fagerlund wrote:
>
> hey,
>
> the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not
> delivered to handler as payload ?
>
> <pre> Example WS Request
>
> GET /demo HTTP/1.1
> Host: example.com
> Connection: Upgrade
> Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
> Sec-WebSocket-Protocol: sample
> Upgrade: WebSocket
> Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
> Origin: http://example.com
>
> ^n:ds[4U
>
>
> </pre>
>
>
> could we get that somehow ...
>
>
>
to do the handshake i need the last 8 byte part thats not delivered by m2 today . for some reson . it has rules for http and json / xml not for some general super extension protocols ... i se it as very natural to be able to extend m2 via handlers and not live in a http://en.wikipedia.org/wiki/Walled_garden_(technology) only watered by zed ;-) avanti ... On Mon, Nov 1, 2010 at 7:34 PM, Peter Fagerlund <admin@iprobot.com> wrote: > Raw Request : > > F09D359F-2A7C-45C9-9311-7ED4D57555AE 2 /chatjs > 457:{"PATH":"/chatjs","host":"127.0.0.1:1234","sec-websocket-key1":"2 [D] > jl53L 36F 319~ Hn > yt0","cookie":"__utma=96992031.97395809.1287150793.1287150793.1287150793.1; > __utmz=96992031.1287150793.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)","origin":"file://","x-forwarded-for":"0.0.0.0","upgrade":"WebSocket","connection":"Upgrade","sec-websocket-key2":"1 > 9 848 4d 1 79 > 6","METHOD":"GET","VERSION":"HTTP/1.1","URI":"/chatjs","PATTERN":"/chatjs"},0:, > > thats whats comming in to handler from m2 from a moo-ws js html page > request ... > > whats "Regular api or Go HTTP api?" ? ... > > best r > > On Mon, Nov 1, 2010 at 7:03 PM, Jim McGrath <jimmc2@gmail.com> wrote: > >> Regular api or Go HTTP api? >> >> If you can send me a copy of the incoming m2 message I can write a test >> case pretty easily. >> >> Jim >> >> On Nov 1, 2010, at 7:50 AM, Peter Fagerlund wrote: >> >> hey, >> >> the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not >> delivered to handler as payload ? >> >> <pre> Example WS Request >> >> GET /demo HTTP/1.1 >> Host: example.com >> Connection: Upgrade >> Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 >> Sec-WebSocket-Protocol: sample >> Upgrade: WebSocket >> Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 >> Origin: http://example.com >> >> ^n:ds[4U >> >> >> </pre> >> >> >> could we get that somehow ... >> >> >> >
By regular I mean the simple one that is described in the documentation as opposed to calling through to the Go HTTP library compatibility code. My implementation of that was more included as a curiosity. If you're calling conn.Recv() then you're using the right API. The mongrel manual implies that they are going to support websockets as/when they can. I don't know much about it but I did see this thread as I was reading around the subject. http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html It looks to me like the mongrel server is not passing the body on. It looks to me like the discussion in the above thread is related, but someone more knowledgable than me would have to comment. The whole M2 architecture is designed around you being able send any bytes you want to any client you want at any time so if you can get the handshake to complete, you're good. Jim On Nov 1, 2010, at 11:44 AM, Peter Fagerlund wrote: > to do the handshake i need the last 8 byte part thats not delivered by m2 today . for some reson . it has rules for http and json / xml not for some general super extension protocols ... > > i se it as very natural to be able to extend m2 via handlers and not live in a http://en.wikipedia.org/wiki/Walled_garden_(technology) only watered by zed ;-) > > avanti ... > > On Mon, Nov 1, 2010 at 7:34 PM, Peter Fagerlund <admin@iprobot.com> wrote: > Raw Request : > > F09D359F-2A7C-45C9-9311-7ED4D57555AE 2 /chatjs 457:{"PATH":"/chatjs","host":"127.0.0.1:1234","sec-websocket-key1":"2 [D] jl53L 36F 319~ Hn yt0","cookie":"__utma=96992031.97395809.1287150793.1287150793.1287150793.1; __utmz=96992031.1287150793.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)","origin":"file://","x-forwarded-for":"0.0.0.0","upgrade":"WebSocket","connection":"Upgrade","sec-websocket-key2":"1 9 848 4d 1 79 6","METHOD":"GET","VERSION":"HTTP/1.1","URI":"/chatjs","PATTERN":"/chatjs"},0:, > > thats whats comming in to handler from m2 from a moo-ws js html page request ... > > whats "Regular api or Go HTTP api?" ? ... > > best r > > On Mon, Nov 1, 2010 at 7:03 PM, Jim McGrath <jimmc2@gmail.com> wrote: > Regular api or Go HTTP api? > > If you can send me a copy of the incoming m2 message I can write a test case pretty easily. > > Jim > > On Nov 1, 2010, at 7:50 AM, Peter Fagerlund wrote: > >> hey, >> >> the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not delivered to handler as payload ? >> >> <pre> Example WS Request >> >> GET /demo HTTP/1.1 >> Host: example.com >> Connection: Upgrade >> Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 >> Sec-WebSocket-Protocol: sample >> Upgrade: WebSocket >> Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 >> Origin: http://example.com >> >> ^n:ds[4U >> >> </pre> >> >> could we get that somehow ... > > >
this "x-forwarded-for":"0.0.0.0" i would like to have more explicit delivered by m2 ... On Mon, Nov 1, 2010 at 7:44 PM, Peter Fagerlund <admin@iprobot.com> wrote: > to do the handshake i need the last 8 byte part thats not delivered by m2 > today . for some reson . it has rules for http and json / xml not for some > general super extension protocols ... > > i se it as very natural to be able to extend m2 via handlers and not live > in a http://en.wikipedia.org/wiki/Walled_garden_(technology) only watered > by zed ;-) > > avanti ... > > On Mon, Nov 1, 2010 at 7:34 PM, Peter Fagerlund <admin@iprobot.com> wrote: > >> Raw Request : >> >> F09D359F-2A7C-45C9-9311-7ED4D57555AE 2 /chatjs >> 457:{"PATH":"/chatjs","host":"127.0.0.1:1234","sec-websocket-key1":"2 >> [D] jl53L 36F 319~ Hn >> yt0","cookie":"__utma=96992031.97395809.1287150793.1287150793.1287150793.1; >> __utmz=96992031.1287150793.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)","origin":"file://","x-forwarded-for":"0.0.0.0","upgrade":"WebSocket","connection":"Upgrade","sec-websocket-key2":"1 >> 9 848 4d 1 79 >> 6","METHOD":"GET","VERSION":"HTTP/1.1","URI":"/chatjs","PATTERN":"/chatjs"},0:, >> >> thats whats comming in to handler from m2 from a moo-ws js html page >> request ... >> >> whats "Regular api or Go HTTP api?" ? ... >> >> best r >> >> On Mon, Nov 1, 2010 at 7:03 PM, Jim McGrath <jimmc2@gmail.com> wrote: >> >>> Regular api or Go HTTP api? >>> >>> If you can send me a copy of the incoming m2 message I can write a test >>> case pretty easily. >>> >>> Jim >>> >>> On Nov 1, 2010, at 7:50 AM, Peter Fagerlund wrote: >>> >>> hey, >>> >>> the last digits in a ws call for upgrade handshake ex "^n:ds[4U" is not >>> delivered to handler as payload ? >>> >>> <pre> Example WS Request >>> >>> GET /demo HTTP/1.1 >>> Host: example.com >>> Connection: Upgrade >>> Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 >>> Sec-WebSocket-Protocol: sample >>> Upgrade: WebSocket >>> Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 >>> Origin: http://example.com >>> >>> ^n:ds[4U >>> >>> >>> </pre> >>> >>> >>> could we get that somehow ... >>> >>> >>> >> >