The Domain and Path field of a parsed cookie have been
the unprocessed wire data since Go 1.0; this seems to
be okay for most applications so let's keep it.
Returning the unprocessed wire data makes it easy to
handle nonstandard or even broken clients without
consulting Raw or Unparsed of a cookie.
The RFC 6265 parsing rules for domain and path are
currently buried in net/http/cookiejar but could be
exposed in net/http if necessary.
R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/48060043
Document what values a PublicSuffixList must accept as
a domain in a call to PublicSuffix.
R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/47560044
Require at least one space after "type" and do not fontify closing
parenthesis of type switch as a type.
R=adonovan
CC=golang-codereviews
https://golang.org/cl/37720050
Use copy rather than a hand rolled loop when moving a partial input
block to the scratch area. This results in a reasonable performance
gain when partial blocks are written.
Benchmarks on Intel(R) Xeon(R) CPU X5650 @ 2.67GHz with Go amd64:
benchmark old MB/s new MB/s speedup
SHA1 BenchmarkHash8Bytes 18.37 22.80 1.24x
SHA256 BenchmarkHash8Bytes 11.86 13.78 1.16x
SHA512 BenchmarkHash8Bytes 4.51 5.24 1.16x
benchmark old ns/op new ns/op delta
SHA1 BenchmarkHash8Bytes 435 350 -19.54%
SHA256 BenchmarkHash8Bytes 674 580 -13.95%
SHA512 BenchmarkHash8Bytes 1772 1526 -13.88%
R=agl, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/35840044
No change to the meaning, just bad writing found by
Doug McIlroy.
Let's start the new year off with a bang.
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/47110044
Most BSDs include the trailing NUL character of the socket path in the
length, however some do not (such as NetBSD 6.99). Handle this by only
subtracting the family and length bytes from the returned length, then
scanning the path and removing any terminating NUL bytes.
Fixes#6627.
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/46420044
Some builders broke on this test; I'm guessing that was because
this test didn't try hard enough to find a different iteration order.
Update #6719
R=dave
CC=golang-codereviews
https://golang.org/cl/47300043
Technically the spec does not guarantee that the iteration order is random,
but it is a property that we have consciously pursued, and so it seems
right to verify that our implementation does indeed randomise.
Update #6719.
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/47010043
This source file, when compiled with gcc 4.4.3 on Ubuntu lucid,
corresponds instruction for instruction to the binaries in the same
directory.
Shipping this source code file resolves http://bugs.debian.org/716853
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/46780043
This change fixes a serious performance regression
with reflect.Value growing to 4 words instead of 3.
The json benchmark was ~50% slower, with this change
it is ~5% slower (and the binary is 0.5% larger).
Longer term, we probably need to rethink our copy
generation. Using REP is really expensive time-wise.
But inlining the copy grows the binary.
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/44990043
Fixes#6952.
runtime.asminit was incorrectly loading runtime.goarm as a word, not a uint8 which made it subject to alignment issues on arm5 platforms.
Alignment aside, this also meant that the top 3 bytes in R11 would have been garbage and could not be assumed to be setting up the FPU reliably.
R=iant, minux.ma
CC=golang-codereviews
https://golang.org/cl/46240043
On Solaris, if you do a in-progress connect, and then the
server accepts and closes the socket, the client's later
attempt to complete the connect will fail with EINVAL. Handle
this case by assuming that the connect succeeded. This code
is weird enough that it is implemented as Solaris-only so that
it doesn't hide a real error on a different OS.
Update #6828
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/46160043