Alexander Emelin

Hello @mehrant95 Client manages reconnects automatically, I guess socket object can't be re-used upon reconnections and should be allocated from scratch each time? Did you look at it? Probably this...

Hello @sidneywidmer I think this was originally done in this way to match a WebSocket behaviour in browsers, where Cookie is only sent for the same origin requests. Because bidirectional...

Thanks for the info and kind words, appreciate! So it's not a huge technical problem of course to add an option to include credentials to cross-origin requests in HTTP-based fallback...

> WebSocket Transport: send cookies to different origin by default Nope, cookies won't be sent to different origin with WebSocket – that's why the concern about different behaviour raised. Yeah,...

Hello, hard to say without a way to reproduce. Can you find a reproducer? How your data looks like? What is the size of it? Also, please provide server configuration.

Thx! I have an idea what could be the problem, will come with a possible fix very soon. In the meanwhile, if you find a reproducer – will be a...

@maithanhtan could you please try 5.2.2 – I believe it should fix the exception. Though a bit shot in the dark since there was no reproducer.

@maithanhtan hello, did you have a chance to try?

Please re-open if the issue persists with 5.2.2

Please note, it seems not enough because the code [here](https://github.com/gorilla/websocket/blob/e064f32e3674d9d79a8fd417b5bc06fa5c6cad8f/conn.go#L776) will panic due to slice bounds out of range (try using `conn.WriteMessage`). It seems that https://github.com/gorilla/websocket/commit/8915bad18b7592fd4503ff0b5accff8a91e75b47 introduced performance regression here...