On Solaris, the MakeRaw and Restore functions of the
x/crypto/ssh/terminal package have been implemented, but on upcoming
platforms such as AIX, Fuchsia and Hurd still have no implementation.
Change-Id: I253249376802273f0160bf3ff1062a66e07b280f
Reviewed-on: https://go-review.googlesource.com/c/147677
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC 7223, Section 3 defines 32 bits for if-index.
RFC 8335, Section 2.1 defines
"If the Interface Identification Object identifies the probed
interface by index, the length is equal to 8 and the payload contains
the if-index [RFC7223]."
The object should be comprised of a 4-byte object header and a 4-byte interface index.
Fixesgolang/go#28530
Change-Id: Ib3ac729b7ec738a90a8c76ef984da0d5b28fa9c9
GitHub-Last-Rev: eba6714ed4
GitHub-Pull-Request: golang/net#23
Reviewed-on: https://go-review.googlesource.com/c/146637
Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com>
Reviewed-by: Mikio Hara <mikioh.public.networking@gmail.com>
This reverts commit e11730110b.
Reason for revert: The reverted test case is one of typical wrong wire
format test cases. The exposed API intentionally doesn't provide any
extenion object validation because the API is also used to construct
wire format compliance test tools. The API is extesion object-agnostic
and should be able to transmit and receive payload containing extension
objects in wrong wire format. Please preserve such test cases for now.
If you want to drop such test case, please add 1) extension object
validation, 2) a control knob for skipping validation, then drop all of
them.
Change-Id: I5c488c95523488e511e7a91e29a2f24f08448415
Reviewed-on: https://go-review.googlesource.com/c/146877
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Go's policy is to only support the past two releases (which is
currently Go 1.11 and Go 1.10). But because App Engine was stuck on Go
1.6 and Go 1.8 for so long, we kept kinda supporting Go 1.6 anyway,
even though we didn't actively test it with any CI system.
But that led to code getting disgusting and full of too many
+build-tagged files and indirection, as this change shows.
So, remove Go 1.8, Go 1.7, and Go 1.6 support. We still "support" Go
1.9 for now, even though it's also not actively tested.
Fixesgolang/go#26302
Change-Id: I4aa5793173e50ffcd67be52a464492ca48fc9a23
Reviewed-on: https://go-review.googlesource.com/c/145677
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Add a JumpIfX instruction which implements conditional jumps using
RegA and RegX. This is in addition to the pre-existing JumpIf
instruction which uses RegA and K.
This instruction / addressing mode is not mentionned in the original BPF
paper, but is supported by tools like bpf_asm, and has recently been
added to the kernel's filter.txt.
Simplify some of the parsing logic, and add a separate helper for
checking for "fake" JumpIfs.
Add JumpIfX support to the BPF vm.
Update testdata with JumpIfX instructions, and add tests
for both the assembler/disassembler and vm.
Fixesgolang/go#27814
Change-Id: I0c3f6ac7eb5b4cd4d9c5af8784ee2e8d25195a0a
GitHub-Last-Rev: 39a88165b2
GitHub-Pull-Request: golang/net#20
Reviewed-on: https://go-review.googlesource.com/c/136895
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We are no longer able to use the kernel bug for detecting the execution
of 386 emulation on 11.2-RELEASE or above kernels. This change uses a
variable that holds the execution mode detected in init instead.
Change-Id: Ib6afdbc40ae1feb8caf040c64c4b01971efc6325
Reviewed-on: https://go-review.googlesource.com/c/139917
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On 11.2-RELEASE or above FreeBSD kernels, the breakage of routing
message alignment for 386 emulation (see COMPAT_FREEBSD32 in
sys/net/rtsock.c) is fixed. This change makes packages in the x/net
repository work regardless of the kernel fix.
Change-Id: Ie71cc7dfb842c66225f96d1fb0e8cc5de7c47015
Reviewed-on: https://go-review.googlesource.com/c/139577
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If there are nested <template> elements and the <template> node isn't in HTML namespace,
couldn't continue to parse documents correctly.
By this patch, it makes the <template> which is in math namespace be skipped on
resetting insertion mode.
Fixesgolang/go#27702
Change-Id: I6eacdb98fe29eb3c61781afca5bc4d83e72ba4ed
Reviewed-on: https://go-review.googlesource.com/136875
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The <isindex> element has been removed from the spec so that the
<template> element doesn't cover it.
To avoid panic, this commit adds ignoring code as a workaround.
Fixesgolang/go#27704
Change-Id: I847391389285df2fc0eb6a795f8c93b481cdebac
Reviewed-on: https://go-review.googlesource.com/136575
Reviewed-by: Nigel Tao <nigeltao@golang.org>
On BSD variaints, for some historical reason, the data format used by raw
ICMP socket may differ from the IPv4 wire format and the format used by
raw IP socket. This change clarifies that input of ParseIPv4Header must
conform to the raw ICMP socket format.
Change-Id: I7288eccaaae0662d0437794098c8f7fc4a55d81e
Reviewed-on: https://go-review.googlesource.com/128216
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On BSD variants, for some historical reason, the data format used by raw
IP socket may differ from the IPv4 wire format. This change clarifies
that input and output of Header type must conform to the raw IP socket
format.
Change-Id: I6ca363f7ea9a3d7645ee81b588785204dee00cba
Reviewed-on: https://go-review.googlesource.com/128215
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This generated 120 kB on the heap before at init, regardless of
whether somebody used http2. Worse, because we vendored it into std,
users would have two copies, for about 256 kB of memory. After CL
127235 that went down to 60 kB per copy, so 120 kB for a binary using
golang.org/x/net/http2 explicitly.
With this, it goes to 0 until one of the two copies in the binary
actually uses one of the http2 packages.
I wasn't able to measure any difference with the Once.Do in the decode
path:
name old time/op new time/op delta
HuffmanDecode-4 732ns ± 8% 707ns ± 3% ~ (p=0.268 n=10+9)
(admittedly noisy)
Change-Id: I6c1065abc0c3458f3cb69e0f678978267ff35ea2
Reviewed-on: https://go-review.googlesource.com/127275
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reduces process-wide heap (inuse_space) by 60kB by using a pointer to
a fixed-sized array instead of a slice of a fixed size.
Before:
119.44kB 23.43% 23.43% 147.88kB 29.01% golang.org/x/net/http2/hpack.addDecoderNode
After:
59.72kB 13.28% 39.85% 87.94kB 19.56% golang.org/x/net/http2/hpack.addDecoderNode
(This is all work from an init func in http2/hpack)
Doesn't seem to affect runtime performance.
Measured with:
$ cat huffman_test.go
package main
import (
"testing"
_ "golang.org/x/net/http2"
)
func TestMem(t *testing.T) {}
$ GODEBUG=memprofilerate=1 go test -memprofilerate=1 -memprofile=mem.prof -v .
=== RUN TestMem
--- PASS: TestMem (0.00s)
PASS
ok huffmem 0.052s
$ go tool pprof --inuse_space mem.prof
Change-Id: I5e56a5a2682f1063c955b342b37e97ca4c303dab
Reviewed-on: https://go-review.googlesource.com/127235
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Implements h2c by leveraging the existing http2.Server by implementing the 2
ways to start an h2c connection as described in RFC 7540, which are: (1)
create a connection starting with HTTP/1 and then upgrading to h2c [Section 3.2]
and (2) starting a connection directly speaking h2c (aka starting with prior
knowledge) [Section 3.4].
For both of the above connection methods the implementation strategy is to
hijack a HTTP/1 connection, perform the h2c connection on the hijacked
net.Conn, and create a suitably configured net.Conn to pass into
http2.Server.ServeConn.
For h2c with prior knowledge this is relatively simple. For that we just have
to verify the HTTP/2 client preface has been written to the net.Conn, and
then reforward the client preface to the hijacked connection.
For h2c upgraded from HTTP/1, this is a bit more involved. First we validate
the HTTP/1 Upgrade request, and respond to the client with 101 Switching
Protocols. Then we write a HTTP/2 client preface on behalf of the client,
and a settings frame and a headers frame which correspond to what was in
the upgrade request. Then since http2.Server is going respond with a
settings ACK, we swallow it so that it is not forwarded to the client since
for h2c upgrade from HTTP/1 the 101 Switching Protocols response replaces
the settins ACK.
Fixesgolang/go#14141
Change-Id: I435f40216c883809c0dcb75426c9c59e2ea31182
Reviewed-on: https://go-review.googlesource.com/112999
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It confused somebody who thought things were hanging because they had
expected to see a response before they started streaming data.
Change-Id: If672956efde3756c966b0c88b9c15ed21daeccba
Reviewed-on: https://go-review.googlesource.com/125644
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If during packing, the byte slice gets re-allocated between packing the
ResourceHeader and ResourceBody, the length will get updated in the old
byte slice before re-allocation resulting in a zero length in the final
packed message.
This change fixes the bug by passing the offset at which the length
should be written instead of a slice of the output byte slice from
ResourceHeader encoding step.
Updates golang/go#16218
Change-Id: Ifd7e2f549b7087ed5b52eaa6ae78970fec4ad988
Reviewed-on: https://go-review.googlesource.com/123835
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We were previously only using the new-ish Request.GetBody to "rewind"
a Request.Body on retry when it seemed that we hadn't started the
read+write body copy process from the old request yet.
Apparently there's a bug somewhere, so this is a safe minimal fix for
now, unconditionally using GetBody when it's available, rather than
only using it when it seems we need to. Should have no performance impact
because it's supposed to be cheap, and this only happens on rare retries
where the server's GOAWAY came in-flight while we were writing a request.
Updates golang/go#25009 (not a fix, but enough for Go 1.11)
Change-Id: Ia462944d4a68cf2fde8d32b7b357b450c509a349
Reviewed-on: https://go-review.googlesource.com/123476
Reviewed-by: Ian Lance Taylor <iant@golang.org>
