Fork me on GitHub
#immutant
<
2016-04-15
>
moizsj07:04:57

@tcrawley: or anyone else seen this error?

io.undertow.websockets.core.WebSocketFrameCorruptedException: UT002015: Extensions not allowed but received rsv of 4
the browser client connects to my immutant websocket server but the connection keeps dropping with the above error. Undertow/web version 2.1.3

moizsj07:04:27

the upgrade negotiation happens OK, and then the channel on-close gets called with the above error.

moizsj09:04:51

some debugging in Undertow shows extensions are not supported. The browser sends a Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits header which I presume is causing the above problem. Any workarounds?

moizsj09:04:16

it works if I do not add the Sec-WebSocket-Extensions: permessage-deflate header in the response (this is custom code i added for adding this header, you might remember the earlier discussion @tcrawley). But we need to support this compression extension header. How do I go about it? I dont need the decompression impl, (my code does the deflating part). All i need is Undertow to allow this extension

moizsj10:04:04

all i need is for immutant (undertow) to allow accepting a message in which RSV bits are set (since it'll be compressed per the above header). and my code will take care of the decompression. Currently, Undertow flags such messages because no extensions are supported

moizsj13:04:17

or if there's a way to leverage the io.undertow.websockets.extensions.PerMessageDeflateHandshake, that'd be perfect. then i can get rid of the custom deflate code we use in the server @tcrawley

tcrawley16:04:06

@moizsj: sorry, I've been neglecting slack. taking a look now

tcrawley16:04:40

@moizsj: I don't see a way for you to set extensions with immutant as it is, but I think we could expose a way for you to pass extensions to immutant.web/run

tcrawley16:04:54

or, we expose the WebSocketProtocolHandshakeHandler and you can add extensions to it directly

moizsj17:04:07

@tcrawley: thanks for that. I am fine with either approach. Whatever allows you to get it out quicker. How soon do you reckon you could have a build out?

tcrawley17:04:26

testing something for you now :)

tcrawley18:04:40

@moizsj: once ^ builds, I'll have some sample code for you

tcrawley18:04:43

and a build :)

moizsj18:04:22

Super @tcrawley So this is expected to be a stable version of wunderboss?

tcrawley18:04:07

yes, it will rely on an incremental build, but the fix will make it into the next wunderboss (and therefore immutant) release

tcrawley18:04:32

@moizsj: if you use Immutant incremental build 726 (http://immutant.org/builds/2x/), you should be able to add extensions like so: https://gist.github.com/a82e004d0180cbc4db20c9f2f6bf7249

moizsj18:04:12

@tcrawley: checking it out..assuming this works, when will it make it to the next proper build?

tcrawley18:04:59

it depends on when we do a release. we don't have one planned currently - this is the only real issue we've had filed against 2.1.3

tcrawley18:04:04

do you have an organizational requirement that prevents using an incremental? or would you just be more comfortable with an official release?

moizsj18:04:46

mostly just about comfort, might not be a deal breaker but will have to check next week on that. btw, same dep should work for web right? [org.immutant/web "2.x.incremental.726"]

tcrawley18:04:38

yes, as long as you have our incremental repo set:

tcrawley18:04:43

:repositories [["Immutant incremental builds"
                  ""]]

moizsj19:04:37

@tcrawley: so it works! though still trying to root cause some intermittent disconnects. What would get me the eqivalent of permessage-deflate; client_no_context_takeover; server_no_context_takeover behaviour on the server?

tcrawley19:04:22

I don't know - I don't know what those no_context_takeover options are

tcrawley19:04:59

the code for PerMessageDeflateHandshake mentions that it supports those options

moizsj19:04:37

@tcrawley: though it works, almost after every message exchange between the server and client, there is a connection drop..

tcrawley19:04:03

do you get an exception?

tcrawley19:04:08

or a ws error code?

moizsj20:04:10

error code 1002 @tcrawley

tcrawley20:04:55

no exceptions on the server-side?

tcrawley20:04:15

or log messages? it looks like the PerMessageDeflateHandshake will log if it gets a parameter it doesn't recognize

moizsj20:04:19

no exceptions..and this is isnt consistently reproducible. I'll try to dig deeper into this next week. but regardless, you've been super helpful as always @tcrawley. when do you expect the 2.1.4 to be out?

tcrawley20:04:59

we haven't scheduled it at all, since we don't really have any issues. but I'd be happy to put one out for you next week if you need it

moizsj20:04:51

that'd be great, will make it much easier for me to adopt it. hopefully i can come back to you on monday and confirm there are no issues with PerMessageDeflateHandshake, and then I'll request you for a 2.1.4. Have a nice weekend!

tcrawley20:04:04

sounds good. you too!

moizsj20:04:30

@tcrawley: actually could i ask you to schedule the 2.1.4 anyway? since the fixes you made today are independent of the PerMessageDeflateHandshake code. And today's fixes most definitely look good, in that they allow you to customize the ws handler.

moizsj20:04:04

so that i have the 2.1.4 on monday which'll allow me to start working on my release