maggie44

> Just built and checked: yes, it does indeed work 👍 > > Otherwise, I suppose this is really an [xterm.js](https://github.com/xtermjs/xterm.js) issue, since that's actually the implementation of the console....

It's not actually the outcome I expected. It seems the requests are being sent as normal, but empty POST requests are what changed. You could try again with the new...

Since we were using Xterm, we ended up exploring WebSocket issues, which turned out to be unrelated. It appears that the commit in the latest release was designed to check...

Fixed for now by reverting the original commit: https://github.com/cloudflare/cloudflared/commit/f407dbb71253a3320b2e54e0ce33a18895d673f9

I think it is probably this commit: https://github.com/cloudflare/cloudflared/commit/e2064c820f32802f58baa027903043fe0ed052e0#diff-6ff9dc179d3cf0539f514218792ce1d93001e2b4835a695bde442ad45edf01deR516 @chungthuang It looks like it used to be that if it is not a websocket (false), then `req.Body` is left as it...

Could someone try this PR out to confirm if it fixes the issue? https://github.com/cloudflare/cloudflared/pull/1340 Clone it, run `make` (assuming you have Golang and make installed) and it will build a...

> Hey [@lukaspj](https://github.com/lukaspj), thanks for the user experience report. > > You are definitely not the first! This is a very common mistake to make. There is one valid use-case...

I think the behaviour described in the first post is what I would have expected: ``` failed to write msg: failed to close writer: failed to acquire lock: context canceled...

Interesting conversation, and I think this thread is turning in to exactly what is needed, a place for people to read through that flushes out the different scenarios. > The...

> Rather I'd like to see it proved useful enough to warrant changing the recommendation from against using it. (Am I right to understand that's what's being discussed here?) 1...