1. 30 Apr, 2019 4 commits
  2. 02 Jan, 2019 1 commit
  3. 14 Dec, 2018 7 commits
  4. 05 Dec, 2018 5 commits
  5. 01 Dec, 2018 1 commit
    • Brad Fitzpatrick's avatar
      http2: revert Transport's strict interpretation of MAX_CONCURRENT_STREAMS · 351d144f
      Brad Fitzpatrick authored
      And add the http2.Transport.StrictMaxConcurrentStreams bool knob to
      behavior being reverted.
      
      In CL 53250 for golang/go#13774 (for Go 1.10) we changed the HTTP/2
      Transport's policy such that a server's advertisement of a
      MAX_CONCURRENT_STREAMS value meant that it was a maximum for the
      entire process, instead of just a single connection.
      
      We thought that was a reasonable interpretation of the spec and
      provided nice safety against slamming a server from a bunch of
      goroutines doing concurrent requests, but it's been largely
      unpopular (see golang/go#27044). It's also different behavior from
      HTTP/1 and because you're usually not sure which protocol version
      you're going to get, you need to limit your outbound HTTP requests
      anyway in case you're hitting an HTTP/1 server.
      
      And nowadays we have the Go 1.11 Transport.MaxConnsPerHost knob too
      (CL 71272 for golang/go#13957). It doesn't yet work for HTTP/2, but it
      will in either Go 1.12 or Go 1.13 (golang/go#27753)
      
      After this is bundled into net/http's, the default HTTP client will
      have this knob set false, restoring the old Go 1.9 behavior where new
      TCP connections are created as necessary. Users wanting the strict
      behavior and import golang.org/x/net/http2 themselves and make a
      Transport with StrictMaxConcurrentStreams set to true. Or they can set
      Transport.MaxConnsPerHost, once that works for HTTP/2.
      
      Updates golang/go#27044 (fixes after bundle into std)
      
      Change-Id: I4efdad7698feaf674ee8e01032d2dfa5c2f8a3a8
      Reviewed-on: https://go-review.googlesource.com/c/151857Reviewed-by: 's avatarAndrew Bonventre <andybons@golang.org>
      351d144f
  6. 29 Nov, 2018 1 commit
  7. 14 Nov, 2018 2 commits
  8. 13 Nov, 2018 2 commits
  9. 08 Nov, 2018 3 commits
  10. 07 Nov, 2018 2 commits
  11. 06 Nov, 2018 2 commits
  12. 02 Nov, 2018 2 commits
    • uhei's avatar
      icmp: fix InterfaceIdent.Index handling · c10e9556
      uhei authored
      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.
      
      Fixes golang/go#28530
      
      Change-Id: Ib3ac729b7ec738a90a8c76ef984da0d5b28fa9c9
      GitHub-Last-Rev: eba6714ed4c7af61e89f6e54d6a7544c570acebb
      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: 's avatarMikio Hara <mikioh.public.networking@gmail.com>
      c10e9556
    • Mikio Hara's avatar
      Revert "icmp: fix ExtendedEchoRequest extension object" · b7e29687
      Mikio Hara authored
      This reverts commit e1173011.
      
      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/146877Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      b7e29687
  13. 01 Nov, 2018 2 commits
  14. 29 Oct, 2018 1 commit
  15. 23 Oct, 2018 1 commit
  16. 17 Oct, 2018 1 commit
  17. 11 Oct, 2018 1 commit
    • Arthur Fabre's avatar
      bpf: support JumpIf on RegX instead of K · 49bb7cea
      Arthur Fabre authored
      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.
      
      Fixes golang/go#27814
      
      Change-Id: I0c3f6ac7eb5b4cd4d9c5af8784ee2e8d25195a0a
      GitHub-Last-Rev: 39a88165b2d3253c37db4b0e303d862b60dc37c9
      GitHub-Pull-Request: golang/net#20
      Reviewed-on: https://go-review.googlesource.com/c/136895Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      49bb7cea
  18. 05 Oct, 2018 1 commit
  19. 04 Oct, 2018 1 commit