Clojurians Log v2

@tcrawley: or anyone else seen this error?

io.undertow.websockets.core.WebSocketFrameCorruptedException: UT002015: Extensions not allowed but received rsv of 4

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

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?

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

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

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

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

@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

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

@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?

testing something for you now :)

Awesome

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

and a build :)

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

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

the relevant wunderboss change is: https://github.com/projectodd/wunderboss/commit/c989c1eaebf936213b4eaffb1d40a18e6338cd9d

@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

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

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

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

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"]

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

:repositories [["Immutant incremental builds"
                  "<http://downloads.immutant.org/incremental/>"]]

@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?

yay!

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

the code for PerMessageDeflateHandshake mentions that it supports those options

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

do you get an exception?

or a ws error code?

error code 1002 @tcrawley

no exceptions on the server-side?

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

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?

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

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!

sounds good. you too!

@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.

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