You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.9 windows/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\Workspace\Go
set GORACE=
set GOROOT=D:\Apps\Scoop\apps\go\current
set GOTOOLDIR=D:\Apps\Scoop\apps\go\current\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\pvl\AppData\Local\Temp\go-build092368419=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
What did you do?
In HTTP/1.1, the only way to figure out if an ResponseWriter has been hijacked is to do a Write(nil) and check the error. But with HTTP/2 there's no concept of hijacking.
The code however, behaves inconsistently, because Write(nil) doesn't end up writing the header in HTTP/1.1. But with HTTP/2, it does a WriteHeader regardless. This ends up in inconsistencies between 1.1 and 2.
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
Write(nil) shouldn't flush the HTTP headers in HTTP/2
What did you see instead?
Write(nil) flushes the headers.
The text was updated successfully, but these errors were encountered:
Sorry, I believe I was mistaken - it seems the headers are not touched only if it's a hijacked connection. Or else HTTP/1.1 writes the headers as well.
This is becoming tedious. Would be nice if there's a way to find out if the connection is Hijacked without forcing a write. Hijacking, like it or not, due to historical reasons is now a part of Http1.1, and is exposed as an interface. While it's good to realize that interface way of exposing things was not the best design, I just wish this was just exposed in the interface. Because, this just make it one more quirk, and causes more problems.
Closing this as the assumption of the issue was incorrect after further digging.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.9 windows/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you do?
In HTTP/1.1, the only way to figure out if an
ResponseWriter
has been hijacked is to do aWrite(nil)
and check the error. But with HTTP/2 there's no concept of hijacking.The code however, behaves inconsistently, because
Write(nil)
doesn't end up writing the header in HTTP/1.1. But with HTTP/2, it does aWriteHeader
regardless. This ends up in inconsistencies between 1.1 and 2.If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
Write(nil)
shouldn't flush the HTTP headers in HTTP/2What did you see instead?
Write(nil)
flushes the headers.The text was updated successfully, but these errors were encountered: