Modify the regex in TestLinuxSendfile to not match the parameters of
the syscall, just its name and the opening parenthesis. This is enough
to recognize that the syscall was invoked.
This fixes the TestLinuxSendfile test when running in Clear Linux,
where strace always execute with -yy implied, having output with extra
information in the parameters:
[pid 5336] sendfile(6<TCP:[127.0.0.1:35007->127.0.0.1:55170]>, 8</home/c/src/go/src/net/http/testdata/index.html>, NULL, 22) = 22
Change-Id: If7639b785d5fdf65fae8e6149a97a57b06ea981c
Reviewed-on: https://go-review.googlesource.com/85657
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I can reproduce with a very short timeout (fractions of a millisecond)
combined with -race.
But given that this is inherently sensitive to actual time, add a
testing mechanism to retry with increasingly large times to compensate
for busy buidlers. This also means the test is usually faster now,
too, since we can start with smaller durations.
Fixes#19608
Change-Id: I3a222464720195849da768e9801eb7b43baa4aeb
Reviewed-on: https://go-review.googlesource.com/82595
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Historically, DetectContentType has returned "text/plain; charset=utf-8"
for an empty body, there was a test for this, and there should continue
to be one.
CL 46631 changed the content-serving handlers to avoid setting any
Content-Type header when serving empty content. Even if that change
in behavior is correct, the CL is explicitly not changing DetectContentType,
so it must also not change DetectContentType's tests.
Change-Id: I7a19c9fabb43be47e349b40e729e49fceb3f2894
Reviewed-on: https://go-review.googlesource.com/82077
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This reverts commit 08f19bbde1b01227fdc2fa2d326e4029bb74dd96.
Reason for revert:
The changed transformation takes effect on a larger set
of code snippets than expected.
For example, this:
func foo() {
// Comment
bar()
}
becomes:
func foo() {
// Comment
bar()
}
This is an unintended consequence.
Change-Id: Ifca88d6267dab8a8170791f7205124712bf8ace8
Reviewed-on: https://go-review.googlesource.com/81335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Panic if an http Handler does:
rw.WriteHeader(0)
... or other invalid values. (for a forgiving range of valid)
I previously made it kinda work in https://golang.org/cl/19130 but
there's no good way to fake it in HTTP/2, and we want HTTP/1 and
HTTP/2 behavior to be the same, regardless of what programs do.
Currently HTTP/2 omitted the :status header altogether, which was a
protocol violation. In fixing that, I found CL 19130 added a test
about bogus WriteHeader values with the comment:
// This might change at some point, but not yet in Go 1.6.
This now changes. Time to be strict.
Updates golang/go#228800
Change-Id: I20eb6c0e514a31f4bba305ac4c24266f39b95fd5
Reviewed-on: https://go-review.googlesource.com/80077
Reviewed-by: Tom Bergan <tombergan@google.com>
Previously, golang.org/cl/75350 updated ReadMIMEHeader to ignore the
first header line when it begins with a leading space, as in the
following example:
GET / HTTP/1.1
Host: foo.com
Accept-Encoding: gzip
However, golang.org/cl/75350 changed ReadMIMEHeader's behavior for the
following example: before the CL it returned an error, but after the
CL it ignored the first line.
GET / HTTP/1.1
Host foo.com
Accept-Encoding: gzip
This change updates ReadMIMEHeader to always fail when the first header
line starts with a space. During the discussion for golang.org/cl/75350,
we realized we had three competing needs:
1. HTTP clients should accept malformed response headers when possible
(ignoring the malformed lines).
2. HTTP servers should reject all malformed request headers.
3. The net/textproto package is used by multiple protocols (most notably,
HTTP and SMTP) which have slightly different parsing semantics. This
complicates changes to net/textproto.
We weren't sure how to best fix net/textproto without an API change, but
it is too late for API changes in Go 1.10. We decided to ignore initial
lines that begin with spaces, thinking that would have the least impact on
existing users -- malformed headers would continue to parse, but the
initial lines would be ignored. Instead, golang.org/cl/75350 actually
changed ReadMIMEHeader to succeed in cases where it previously failed
(as in the above example).
Reconsidering the above two examples, there does not seem to be a good
argument to silently ignore ` Host: foo.com` but fail on ` Host foo.com`.
Hence, this change fails for *all* headers where the initial line begins
with a space.
Updates #22464
Change-Id: I68d3d190489c350b0bc1549735bf6593fe11a94c
Reviewed-on: https://go-review.googlesource.com/80055
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We set Content-Type to "text/plain; charset=utf-8" even with blank body
before. Let's strip this unnecessary header though it's harmless in most
cases.
Fixes#20784
Signed-off-by: Tw <tw19881113@gmail.com>
Change-Id: Ic58a410dcbc89f457c6ddd92961d9cbf545b2f4f
Reviewed-on: https://go-review.googlesource.com/46631
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously when RoundTrip returned a non-nil error, the proxy returned a
StatusBadGateway error, instead of first calling ModifyResponse. This
commit first calls ModifyResponse, whether or not the error returned
from RoundTrip is nil.
Also closes response body when ModifyResponse returns an error. See #22658.
Fixes#21255
Change-Id: I5b5bf23a69ae5608f87d4ece756a1b4985ccaa9c
Reviewed-on: https://go-review.googlesource.com/54030
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
See CL 40291. ctx.Err() is defined to only return non-nil exactly
when ctx.Done() returns a closed channel.
Change-Id: I12f51d8c42228f759273319b3ccc28012cb9fc73
Reviewed-on: https://go-review.googlesource.com/71310
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A header line with leading whitespaces is not valid in HTTP as per
RFC7230. This change ignores these invalid lines in ReadMIMEHeader.
Updates #22464
Change-Id: Iff9f00380d28a9617a55ff7888a76fba82001402
Reviewed-on: https://go-review.googlesource.com/75350
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The godoc for RoundTrip already specifies when it's ok to reuse a
request that contains a body: the caller must wait until RoundTrip
calls Close on Request.Body.
This CL adds a small clarification: If the request does not have a
body, it can be reused as long as the caller does not mutate the
Request until RoundTrip fails or the Response.Body is closed.
Fixes#19653
Change-Id: I56652a9369978d11650e2e6314104831c2ce5e78
Reviewed-on: https://go-review.googlesource.com/75671
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing implementation names a c net.Conn return which is
never user. Leaving the returns unamed is marginally clearer.
Change-Id: If9a411c9235b78c116a8ffb21fef71f7a4a4ce8f
Reviewed-on: https://go-review.googlesource.com/66890
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updates #22540
Change-Id: I26e79c25652976fac6f2e5a7afb4fd1240996d74
Reviewed-on: https://go-review.googlesource.com/75531
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
To improve readability when exported fields are removed,
forbid the printer from emitting an empty line before the first comment
in a const, var, or type block.
Also, when printing the "Has filtered or unexported fields." message,
add an empty line before it to separate the message from the struct
or interfact contents.
Before the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
After the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
Fixes#18264
Change-Id: I9fe17ca39cf92fcdfea55064bd2eaa784ce48c88
Reviewed-on: https://go-review.googlesource.com/71990
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In CL 50510, the Content-Type header started to be set in Redirect when
request method is GET. (Prior to that, it wasn't set at all, which is
what said CL was fixing.) However, according to HTTP specification,
the expected response for a HEAD request is identical to that of a
GET request, but without the response body.
This CL updates the behavior to set the Content-Type header for HEAD
method in addition to GET.
This actually allows a simpler implementation than before. This change
largely reverts CL 50510, and applies the simpler implementation.
Add a test for Content-Type header and body for GET, HEAD requests.
Updates CL 50510.
Change-Id: If33ea3f4bbc5246bb5dc751458004828cfe681b9
Reviewed-on: https://go-review.googlesource.com/65190
Run-TryBot: Dmitri Shuralyov <shurcool@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
When run `go doc -u http.connectMethod`, the whole table is treated as
a single long line. This commit inserts `\t` at the begining of each line,
so the table can be displayed properly in `go doc`.
Change-Id: I6408efd31f84c113e81167d62e1791643000d629
Reviewed-on: https://go-review.googlesource.com/74651
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Simplify how pprof attaches the handlers to the DefaultMux by using
http.HandleFunc instead of manually wrapping the handlers in
a http.HandlerFunc.
Change-Id: I65db262ebb2e29e4b6f30df9d2688f5daf782c29
Reviewed-on: https://go-review.googlesource.com/71251
Reviewed-by: Sam Whited <sam@samwhited.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Sam Whited <sam@samwhited.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Header.WriteSubset uses a sync.Pool but wouldn't Put the sorter back in
the pool if there was an error writing to the io.Writer
I'm not really sure why the sorter is returned to begin with. The
comment says "for possible return to headerSorterCache".
This also doesn't address potential panics that might occur, but the
overhead of doing the Put in a defer would likely be too great.
Change-Id: If3c45a4c3e11f6ec65d187e25b63455b0142d4e3
Reviewed-on: https://go-review.googlesource.com/73910
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
A 1XX, 204, or 304 response may not include a response body according
to RFC 7230, section 3.3.3. If a buggy server returns a 204 or 304
response with a body that is chunked encoded, the invalid body is
currently made readable in the Response. This can lead to data races due
to the transport connection's read loop which does not wait for the body
EOF when the response status is 204 or 304.
The correct behavior is to ignore the body on a 204 or 304 response, and
treat the body data as the beginning of the next request on the
connection.
Updates #22330.
Change-Id: I89a457ceb783b6f66136d5bf9be0a9b0a04fa955
Reviewed-on: https://go-review.googlesource.com/71910
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Tom Bergan <tombergan@google.com>
Updates http2 to x/net/http2 git rev 1087133bc4a for:
http2: reject DATA frame before HEADERS frame
https://golang.org/cl/56770
http2: respect peer's SETTINGS_MAX_HEADER_LIST_SIZE in ClientConn
https://golang.org/cl/29243
http2: reset client stream after processing response headers
https://golang.org/cl/70510
Also updated TestRequestLimit_h2 as the behavior changed slightly due
to https://golang.org/cl/29243.
Fixes#13959Fixes#20521Fixes#21466
Change-Id: Iac659694f3a48b8bd485546a4f96a932e3056026
Reviewed-on: https://go-review.googlesource.com/71611
Run-TryBot: Tom Bergan <tombergan@google.com>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If the client sends a request with a custom Host header and receives
a relative redirect in response, the second request should use the
same Host header as the first request. However, if the response is
an abolute redirect, the Host header should not be preserved. See
further discussion on the issue tracker.
Fixes#22233
Change-Id: I8796e2fbc1c89b3445e651f739d5d0c82e727c14
Reviewed-on: https://go-review.googlesource.com/70792
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I50389752dcbf5d058ce11256a414be7955cdb77f
Reviewed-on: https://go-review.googlesource.com/71070
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Check to ensure that Status is set
when parsing a proxied HTTPS response
that a CONNECT proxy-authorization.
Fixes#21701
Change-Id: Id91700b83425420101e0b0d46e12aaf5d20fd3a3
Reviewed-on: https://go-review.googlesource.com/59990
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
Fixes#22084.
Change-Id: If405ffdc57fcf81de3c0e8473c45fc504db735bc
Reviewed-on: https://go-review.googlesource.com/67410
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Change-Id: Ic3f7f575d3640706adb7d64545ed8027add6c58f
Reviewed-on: https://go-review.googlesource.com/61350
Run-TryBot: Tom Bergan <tombergan@google.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
strings.LastIndexByte was introduced in go1.5 and it can be used
effectively wherever the second argument to strings.LastIndex is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.LastIndex.
Change-Id: I7b5679d616197b055cffe6882a8675d24a98b574
Reviewed-on: https://go-review.googlesource.com/66372
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Transport.Proxy is documented as only supporting the http and socks5
schemes. If one tries to use it for https URLs, they end up with a
cryptic error like:
http: TLS handshake error from [...]: tls: oversized record received with length 20037
This is because Transport simply skips TLS if Proxy is non-nil, since it
knows it doesn't support Proxy with https.
However, that error is very confusing and it can take a while to figure
out what's going on. Instead, error if Proxy is used and it returns an
unsupported scheme.
Updates #19493.
Change-Id: Ia036357011752f45bb9b8282a4ab5e31bc8d1a69
Reviewed-on: https://go-review.googlesource.com/66010
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
strings.IndexByte was introduced in go1.2 and it can be used
effectively wherever the second argument to strings.Index is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.Index.
Change-Id: I1ab5edb7c4ee9058084cfa57cbcc267c2597e793
Reviewed-on: https://go-review.googlesource.com/65930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Calling response.Body.Close() early would generarate a race before this.
Since closing would return early before the main code path had a chance
to reset the request canceler. Having a non-nil request canceler at the
start of the next request would cause a "request canceled" error.
Here we simply wait for the eofc channel to be closed before returning
from earlyCloseFn, ensuring that the caller won't be re-using that
Request object before we have a chance to reset the request canceler to
nil.
Fixes#21838
Change-Id: I641815526c6ac63d1816c9b6ad49d73715f7a5cb
Reviewed-on: https://go-review.googlesource.com/62891
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Ensure that the implicitly created redirect
for
"/route"
after
"/route/"
has been registered doesn't lose the query string information.
A previous attempt (https://golang.org/cl/43779) changed http.Redirect, however, that change broke direct calls to http.Redirect.
To avoid that problem, this change touches ServeMux.Handler only.
Fixes#17841
Change-Id: I303c1b1824615304ae68147e254bb41b0ea339be
Reviewed-on: https://go-review.googlesource.com/61210
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
