Ryo Ota

I have the same error, but I could not reproduce it 100% yet. I will continue to investigate.

I've found a 100% reproducible case. A sender uses HTTP/1.1 over TLS and a receiver uses plain HTTP/1.1. ```bash # sender curl -T- --http1.1 -k https://localhost:8443/mydata ``` ```bash # receiver...

I assume your receiver closed for some reason and the server emitted the error. I'm still not sure why the server behaves differently in plain HTTP/1.1 and HTTP/1.1 over TLS.

What are your HTTP clients? Google Chrome? --- If you are intereseted in what protocol is used and the frontend is a browser, try the following steps. Open a browser...

@perlerer Could you check the server supports data streaming? You can use `curl` like the following video: https://github.com/nwtgck/piping-server/assets/10933561/fa696460-23a5-4264-8fcd-4ecb39b6e219 ```bash # sender curl -T- https://ppng.io/mytext ``` ```bash # receiver curl https://ppng.io/mytext...

I also tried to `[Either (Named AST.Instruction) (Named AST.Terminator)]`, but it didn't work. I think both `[Either (Named AST.Instruction) (Named AST.Terminator)]` and ` [Either AST.Instruction AST.Terminator]` is better to support...

@dependabot rebase

The server may not support streaming request or response. Try the following commands in different terminals. ```bash seq inf | curl -T- https://piping.example.com/mypath ``` ```bash curl https://piping.example.com/mypath ``` The expected...

> So the go-piping-tunnel not suitable for long time running in backgroud. I understand what the issue is now. I have been thinking about a feature for long time running....