An error occurred fetching the project authors.
- 25 Jan, 2016 1 commit
-
-
Brad Fitzpatrick authored
Thanks to Régis Leroy for noticing. Change-Id: I5ca2402efddab4e63d884a9d315fc1394e514cb7 Reviewed-on: https://go-review.googlesource.com/18871Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 10 Nov, 2015 1 commit
-
-
Brad Fitzpatrick authored
Fixes #13135 Change-Id: I45666f32cd91102211bf01a306edcb10deb65187 Reviewed-on: https://go-review.googlesource.com/16680 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 08 Sep, 2014 1 commit
-
-
Russ Cox authored
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.
-
- 21 Jul, 2014 1 commit
-
-
Brad Fitzpatrick authored
LGTM=rsc R=rsc, dan.kortschak CC=golang-codereviews, r https://golang.org/cl/115840046
-
- 29 Jan, 2014 1 commit
-
-
Brad Fitzpatrick authored
This is the chunked half of https://golang.org/cl/49570044 . We want full reads to return EOF as early as possible, when we know we're at the end, so http.Transport client connections are eagerly re-used in the common case, even if no Read or Close follows. To do this, make the chunkedReader.Read fill up its argument p []byte buffer as much as possible, as long as that doesn't involve doing any more blocking reads to read chunk headers. That means if we have a chunk EOF ("0\r\n") sitting in the incoming bufio.Reader, we see it and set EOF on our final Read. LGTM=adg R=adg CC=golang-codereviews https://golang.org/cl/58240043
-
- 19 Jan, 2014 1 commit
-
-
Brad Fitzpatrick authored
Use testing.AllocsPerRun now that it exists, instead of doing it by hand. Fixes #6076 R=golang-codereviews, alex.brainman CC=golang-codereviews https://golang.org/cl/53810043
-
- 20 Nov, 2012 2 commits
-
-
Shenghou Ma authored
R=fullung, bradfitz, dave CC=golang-dev https://golang.org/cl/6846081
-
Brad Fitzpatrick authored
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
-
- 09 Nov, 2011 1 commit
-
-
Andrew Gerrand authored
Arrange the code so that it's easier to keep edits in sync. R=golang-dev, mikioh.mikioh, bradfitz, andybalholm, rsc CC=golang-dev https://golang.org/cl/5345041
-
- 04 Nov, 2011 1 commit
-
-
Brad Fitzpatrick authored
This moves DumpRequest, DumpResponse, NewChunkedReader, and NewChunkedWriter out of http, as part of the continued http diet plan. Also, adds DumpRequestOut (for dumping outbound requests), since DumpRequest's ambiguity (the "wire representation" in what direction?) was often a source of confusion and bug reports. R=rsc, adg CC=golang-dev https://golang.org/cl/5339041
-