-
Notifications
You must be signed in to change notification settings - Fork 18k
x/net/http2: bidirection streams, write request body data as available #13444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
When you say "streams", you don't mean anything more specific than being able to read & write response bodies and/or (?) request bodies at the same time? For the client side, can't you just do a RoundTrip with the Request.Body set to the read end of an io.Pipe and then write your stderr/stdout to the write side? I just put up an type capitalizeReader struct {
r io.Reader
}
func (cr capitalizeReader) Read(p []byte) (n int, err error) {
n, err = cr.r.Read(p)
for i, b := range p[:n] {
if b >= 'a' && b <= 'z' {
p[i] = b - ('a' - 'A')
}
}
return
}
type flushWriter struct {
w io.Writer
}
func (fw flushWriter) Write(p []byte) (n int, err error) {
n, err = fw.w.Write(p)
if f, ok := fw.w.(http.Flusher); ok {
f.Flush()
}
return
}
func echoCapitalHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "PUT" {
http.Error(w, "PUT required.", 400)
return
}
io.Copy(flushWriter{w}, capitalizeReader{r.Body})
} And then with a couple modifications to the http2 client, I can now stream an HTTP request body to a server, and read the streamed response body at the same time, even seeing the 1 second delays:
Do you need more than that? The change is at https://golang.org/cl/17310 if you want to patch it in and play. (In your $GOPATH/src/net directory, run |
CL https://golang.org/cl/17310 mentions this issue. |
@bradfitz this looks quite promising. I'm in meetings most of today, so I doubt I'll have time to fiddle, but hopefully I will tomorrow. @smarterclayton WDYT about this? |
@bradfitz I'm finally getting some time to look at this. If I have a normal |
Once that change is submitted you wouldn't need to modify the http2 source. You'd just write: package main
import (
"net/http"
"golang.org/x/net/http2"
)
func main() {
c := &http.Client{Transport: &http2.Transport{AllowResponseBeforeBody: true}}
....
} |
Thanks! |
Actually, I'm removing the option. It'll just be on by default. You won't even need to import "golang.org/x/net/http2" as of Go 1.6. |
Unlike HTTP/1, we now permit streaming the write of a request body as we read the response body, since HTTP/2's framing makes it possible. Our behavior however is based on a heuristic: we always begin writing the request body right away (like previously, and like HTTP/1), but if we're still writing the request body and the server replies with a status code over 299 (not 1xx and not 2xx), then we stop writing the request body, assuming the server doesn't care about it. There is currently no switch (and hopefully won't be) to force enable this behavior. In the case where the server replied with a 1xx/2xx and we're still writing the request body but the server doesn't want it, the server can do a RST_STREAM, which we respect as before and stop sending. Also in this CL: * adds an h2demo handler at https://http2.golang.org/ECHO to demo it * fixes a potential flow control integer truncation bug * start of clientTester type used for the tests in this CL, similar to the serverTester. It's still a bit cumbersome to write client tests, though. * fix potential deadlock where awaitFlowControl could block while waiting a stream reset arrived. fix it by moving all checks into the sync.Cond loop, rather than having a sync.Cond check followed by a select. simplifies code, too. * fix two data races in test-only code. Updates golang/go#13444 Change-Id: Idfda6833a212a89fcd65293cdeb4169d1723724f Reviewed-on: https://go-review.googlesource.com/17310 Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com>
Even better 😄 I did get a chance to play around a bit yesterday. Our setup is a bit complicated, because have a proxy in the middle, so the flow is client -> proxy -> backend (and it ultimately connects to a Docker exec session). I was able to hack the proxy to get it to somewhat support proxying HTTP/2, and I was able to successfully round trip a request from the client to the backend and back. The one thing I didn't get working was interactive input and the output coming back immediately. I'm not sure if it's an issue with the way I was trying to proxy the request through, or what, but I'll come back to it at some point in my spare time. To illustrate what wasn't working correctly:
The output from |
Yeah, the change just submitted even has a couple new tests showing that this works (and will prevent it from ever not working in the future). So I suspect your proxy is buffering a bit too hard. |
CL https://golang.org/cl/17570 mentions this issue. |
Fixes #12796 Updates #13444 Change-Id: I56840c0baf9b32a683086a80f5db1c5ea0a7aedf Reviewed-on: https://go-review.googlesource.com/17680 Reviewed-by: Russ Cox <rsc@golang.org>
In Kubernetes, we are currently using spdystream as a means to support bidirectional stream-based communication over HTTP connections. We use this to enable ssh-like connectivity and port forwarding from the user's system into a Docker container running in Kubernetes.
The spdystream APIs enable us to create streams at will in both the client and server handler code. For remote command execution, the client creates streams representing stdin, stdout, and stderr. Once the server receives all the streams, it performs a
docker exec
of whatever process the user wishes, and data is copied between the container process's stdin/stdout/stderr and the spdy streams.We're hoping that we can eventually move to HTTP/2 and achieve the same functionality; namely, full control over stream creation and data flow in a "hijacked" fashion.
cc @bradfitz @smarterclayton @thockin @lavalamp
(forked from #13443)
The text was updated successfully, but these errors were encountered: