When FlushInterval is specified on ReverseProxy, the ResponseWriter is
wrapped with a maxLatencyWriter that periodically flushes in a
goroutine. That goroutine was not being cleaned up at the end of the
request. This resulted in a panic when Flush() was being called on a
ResponseWriter that was closed.
The code was updated to always send the done message to the flushLoop()
goroutine after copying the body. Futhermore, the code was refactored to
allow the test to verify the maxLatencyWriter behavior.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6033043
below do not support '.
This makes package html consistent with package text/template's
HTMLEscape function.
Fixes#3489.
R=rsc, mikesamuel, dsymonds
CC=golang-dev
https://golang.org/cl/5992071
The shouldEscape function did not correctly escape the reserved characters listed in RFC 3986 §2.2, breaking some strict web servers.
Fixes#3433.
R=rsc
CC=golang-dev
https://golang.org/cl/5970050
Tested using 6g and gccgo on x86_64 GNU/Linux and using gccgo
on PowerPC GNU/Linux (which is big-endian).
R=golang-dev, bradfitz, mikioh.mikioh, iant
CC=golang-dev
https://golang.org/cl/5975073
The old way to find a port was to listen :0 and then
look at what port it picked, close the listener, and then
immediately try to listen on that port.
On some Windows 7 machines that sequence fails at
the second listen, because the first one is still lingering
in the TCP/IP stack somewhere. (Ironically, most of these
are used in tests of a "second listen", which in this case
ends up being the third listen.)
Instead of this race, just return the listener from the
function, replacing usableLocalPort+Listen with
usableListenPort.
Fixes#3219.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5769045
I don't know what's out there, but something
is answering to 127.0.71.111:80 on our builder,
so use a different port.
Also insert a check that the dial fails, which
would have diagnosed this problem.
Fixes#3016.
R=golang-dev, mikioh.mikioh, r
CC=golang-dev
https://golang.org/cl/5754062
I don't know enough about multicast.
Should this be disabled on all systems, not just Windows?
R=golang-dev
CC=golang-dev
https://golang.org/cl/5754060
By default the all.bash tests must not ever announce
on an external address. It's not just an OS X issue.
R=golang-dev, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5753067
* Splits into three server tests.
- TestStreamConnServer for tcp, tcp4, tcp6 and unix networks
- TestSeqpacketConnServer for unixpacket networks
- TestDatagramPacketConnServer for udp, udp4, udp6 and unixgram networks
* Adds both PacketConn and Conn test clients to datagram packet conn tests.
* Fixes wildcard listen test cases on dual IP stack platform.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5701066
This CL changes the behavior of Dial and Listen API family.
Previous Dial and Listen allow a combo of "tcp6" and IPv4 or IPv6
IPv4-mapped address as its argument, but it also makes slightly
different behaviors between Linux and other platforms. This CL fixes
such differences across over platforms by tweaking IP-level socket
option IPV6_V6ONLY. Consequently new Dial and Listen API family will
reject arguments consists of "tcp6" and IPv4 or IPv6 IPv4-mapped
address.
This CL also adds a bit clarified unicast listener tests.
Fixes#2581.
R=rsc, minux.ma
CC=golang-dev
https://golang.org/cl/5677086
go test -short # like in the build; no external stuff
go test # long tests, + external
go test -external=false # long tests, no external
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5696079
Fixes#2919 I believe. (gets as far as sending a CONNECT
request to my little dummy logging proxy that doesn't actually
support CONNECT now.) Untested with a real CONNECT-supporting
proxy, though.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5708055
We should use DialUnix or ListenPacket for unixgram networks
because Dial doesn't take a local UnixAddr.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5706043
This fixes the build of package net for GOOS=NetBSD.
Of course, a real implementation would be even better.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5693065
Makes it possible for client code to maintain its own profiles,
and also reduces the API surface by giving us a type that
models built-in profiles.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5684056
Accept certain non-compliant response headers
(in particular, when spaces preceed the colon).
All major browser and curl seem to support this,
and at least one webserver seems to send these.
*shrug*
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5690059
Before we were using "ESMTP" in the banner as a clue,
but that is not required by the RFC and breaks mailing
to smtp.yandex.ru.
Fixes#3045.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5687066
The panic happens if -benchtime flag is specified:
go test -bench=EndToEndAsyncHTTP -benchtime=120
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5677075
Convert cryptotype to general go1rename fix.
Add os.Exec -> syscall.Exec fix along with new
URL fixes.
Fixes#2946.
R=golang-dev, r, dsymonds
CC=golang-dev
https://golang.org/cl/5672072
The set of errors forwarded by the os package varied with system and
was therefore non-portable.
Three helpers added for portable error checking: IsExist, IsNotExist, and IsPermission.
One or two more may need to come, but let's keep the set very small to discourage
thinking about errors that way.
R=mikioh.mikioh, gustavo, r, rsc
CC=golang-dev
https://golang.org/cl/5672047
Whoops. Consume the body of the first request
before making the subsequent /quit request.
R=golang-dev, untheoretic
CC=golang-dev
https://golang.org/cl/5674054
Apparently some distros don't let you ptrace attach
to your own existing processes.
Run strace on the child directly, instead, which
reportedly is more often allowed, and makes the
code simpler too.
R=golang-dev, n13m3y3r
CC=golang-dev
https://golang.org/cl/5675050
* add -work option to save temporary files (Fixes issue 2980)
* fix go test -i to work with cgo packages (Fixes issue 2936)
* do not overwrite/remove empty directories or non-object
files during build (Fixes issue 2829)
* remove package main vs package non-main heuristic:
a directory must contain only one package (Fixes issue 2864)
* to make last item workable, ignore +build tags for files
named on command line: go build x.go builds x.go even
if it says // +build ignore.
* add // +build ignore tags to helper programs
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/5674043
Once we've evicted all the blocked I/O, the ref count
should go to zero quickly, so it should be safe to
postpone the close(2) until then.
Fixes#1898.
Fixes#2116.
Fixes#2122.
R=golang-dev, mikioh.mikioh, bradfitz, fullung, iant
CC=golang-dev
https://golang.org/cl/5649076
Filed issue 3016 to fix this, but I really want
to see a "ok" in the Windows column so we
know what is and is not working.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5658050
Now with a bit more paranoia and lower number of requests
to keep it under the default OS X 256 fd limit.
R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/5659051
Generates an infinite stream (at least >1GB) of:
=== RUN TestTransportPersistConnLeak
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
2012/02/13 22:20:19 http: Accept error: accept tcp 127.0.0.1:63972:
too many open files
R=bradfitz
CC=golang-dev
https://golang.org/cl/5661052