We need to wait for the handler to actually finish running,
not almost be done running.
This was always a bug, but now that handler output is buffered
it shows up easily on GOMAXPROCS >1 systems.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7109043
This introduces a buffer between writing from a handler and
writing chunks. Further, it delays writing the header until
the first full chunk is ready. In the case where the first
full chunk is also the final chunk (for small responses), that
means we can also compute a Content-Length, which is a nice
side effect for certain benchmarks.
Fixes#2357
R=golang-dev, dave, minux.ma, rsc, adg, balasanjay
CC=golang-dev
https://golang.org/cl/6964043
The old code made it impossible to implement a reverse proxy
with anything less than 4k write granularity to the backends.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7060059
TimeoutHandler was changed from "ns int64" to "dt time.Duration" on
Nov 30, 2011, but the godoc still refers to "ns".
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7031050
It already did so for its sibling, *strings.Reader, as well as *bytes.Buffer.
R=edsrzf, dave, adg, kevlar, remyoudompheng, adg, rsc
CC=golang-dev
https://golang.org/cl/7031045
Request.URL had no documentation before and some people were expecting all fields to be populated.
Fixes#3805.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7008046
NO_PROXY="example.com" should match "foo.example.com", just
the same as NO_PROXY=".example.com". This is what curl and
Python do.
Fixes#4574
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7005049
Also, implement a global OPTIONS * handler, like Apache.
Permit sending "*" requests to handlers, but not path-based
(ServeMux) handlers. That means people can go out of their
way to support SSDP or SIP or whatever, but most users will be
unaffected.
See RFC 2616 Section 5.1.2 (Request-URI)
See RFC 2616 Section 9.2 (OPTIONS)
Fixes#3692
R=rsc
CC=golang-dev
https://golang.org/cl/6868095
Can happen in both request and response.
Also use it in one place that wasn't.
Fixes#3997.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6903057
Per the curl man page, the http_proxy configuration can be
of the form:
[protocol://]<host>[:port]
And we had a test that <ip>:<port> worked, but if
the host began with a letter, url.Parse parsed the hostname
as the scheme instead, confusing ProxyFromEnvironment.
R=golang-dev
CC=golang-dev
https://golang.org/cl/6875060
RFC 2616: "The 204 response MUST NOT include a message-body,
and thus is always terminated by the first empty line after
the header fields."
Previously we'd trigger chunked encoding by default on
responses, and then when finishing the request we'd write the
chunk trailers, which counted as a message-body.
Fixes#4454
R=golang-dev
CC=golang-dev
https://golang.org/cl/6782139
Test creates 2 tcp connections for put and get. Make sure
these are closed properly after test is over, otherwise
server hangs waiting for connection to be closed.
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/6842109
Thanks to Dustin Sallings for exposing the most frustrating
bug ever, and for providing repro cases (which formed the
basis of the new tests in this CL), and to Dave Cheney and
Dmitry Vyukov for help debugging and fixing.
This CL depends on submited pollster CLs ffd1e075c260 (Unix)
and 14b544194509 (Windows), as well as unsubmitted 6852085.
Some operating systems (OpenBSD, NetBSD, ?) may still require
more pollster work, fixing races (Issue 4434 and
http://goo.gl/JXB6W).
Tested on linux-amd64 and darwin-amd64, both with GOMAXPROCS 1
and 4 (all combinations of which previously failed differently)
Fixes#4191
Update #4434 (related fallout from this bug)
R=dave, bradfitz, dsallings, rsc, fullung
CC=golang-dev
https://golang.org/cl/6851061
Should make BSDs more reliable. (they seem to reuse ports
quicker than Linux)
Tested by hand with local modifications to force reuse on
Linux. (net/http tests failed before, pass now) Details in the
issue.
Fixes#4436
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/6847101
Noticed this while closing tabs. Yesterday I thought I could
ignore this garbage and hope that a fix for issue 2205 handled
it, but I just realized that's the opposite case,
string->[]byte, whereas this is []byte->string. I'm having a
hard time convincing myself that an Issue 2205-style fix with
static analysis and faking a string header would be safe in
all cases without violating the memory model (callee assumes
frozen memory; are there non-racy ways it could keep being
modified?)
R=dsymonds
CC=dave, gobot, golang-dev
https://golang.org/cl/6850067
This is a simplified version of earlier versions of this CL
and now only fixes obviously incorrect things, without
changing the locking on bodyEOFReader.
I'd like to see if this is sufficient before changing the
locking.
Update #4191
R=golang-dev, rsc, dave
CC=golang-dev
https://golang.org/cl/6739055
When HTTP bodies were too large and we didn't want to finish
reading them for DoS reasons, we previously found it necessary
to send a FIN and then pause before closing the connection
(which might send a RST) if we wanted the client to have a
better chance at receiving our error response. That was Issue 3595.
This issue adds the same fix to request headers which
are too large, which might fix the Windows flakiness
we observed on TestRequestLimit at:
http://build.golang.org/log/146a2a7d9b24441dc14602a1293918191d4e75f1
R=golang-dev, alex.brainman, rsc
CC=golang-dev
https://golang.org/cl/6826084
Fix the problem with no cookie handling when sending
other than GET or HEAD request through
(*Client) Do(*Request) (*Resposne, error).
https://code.google.com/p/go/issues/detail?id=3985
Adds a function (*Client) send(*Request) (*Reponse, error):
- sets cookies from CookieJar to request,
- sends request
- parses a reply cookies and updates CookieJar
Fixes#3985
R=bradfitz
CC=gobot, golang-dev
https://golang.org/cl/6653049