1. 30 Nov, 2017 6 commits
  2. 29 Nov, 2017 22 commits
  3. 28 Nov, 2017 9 commits
  4. 27 Nov, 2017 3 commits
    • Brad Fitzpatrick's avatar
      net/http: panic on invalid WriteHeader status code · 18ae4c83
      Brad Fitzpatrick authored
      Panic if an http Handler does:
      
          rw.WriteHeader(0)
      
      ... or other invalid values. (for a forgiving range of valid)
      
      I previously made it kinda work in https://golang.org/cl/19130 but
      there's no good way to fake it in HTTP/2, and we want HTTP/1 and
      HTTP/2 behavior to be the same, regardless of what programs do.
      Currently HTTP/2 omitted the :status header altogether, which was a
      protocol violation. In fixing that, I found CL 19130 added a test
      about bogus WriteHeader values with the comment:
      
        // This might change at some point, but not yet in Go 1.6.
      
      This now changes. Time to be strict.
      
      Updates golang/go#228800
      
      Change-Id: I20eb6c0e514a31f4bba305ac4c24266f39b95fd5
      Reviewed-on: https://go-review.googlesource.com/80077Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
      18ae4c83
    • Tom Bergan's avatar
      net/textproto: reject all headers with a leading space · 1c69384d
      Tom Bergan authored
      Previously, golang.org/cl/75350 updated ReadMIMEHeader to ignore the
      first header line when it begins with a leading space, as in the
      following example:
      
      GET / HTTP/1.1
        Host: foo.com
      Accept-Encoding: gzip
      
      However, golang.org/cl/75350 changed ReadMIMEHeader's behavior for the
      following example: before the CL it returned an error, but after the
      CL it ignored the first line.
      
      GET / HTTP/1.1
        Host foo.com
      Accept-Encoding: gzip
      
      This change updates ReadMIMEHeader to always fail when the first header
      line starts with a space. During the discussion for golang.org/cl/75350,
      we realized we had three competing needs:
      
      1. HTTP clients should accept malformed response headers when possible
         (ignoring the malformed lines).
      
      2. HTTP servers should reject all malformed request headers.
      
      3. The net/textproto package is used by multiple protocols (most notably,
         HTTP and SMTP) which have slightly different parsing semantics. This
         complicates changes to net/textproto.
      
      We weren't sure how to best fix net/textproto without an API change, but
      it is too late for API changes in Go 1.10. We decided to ignore initial
      lines that begin with spaces, thinking that would have the least impact on
      existing users -- malformed headers would continue to parse, but the
      initial lines would be ignored. Instead, golang.org/cl/75350 actually
      changed ReadMIMEHeader to succeed in cases where it previously failed
      (as in the above example).
      
      Reconsidering the above two examples, there does not seem to be a good
      argument to silently ignore ` Host: foo.com` but fail on ` Host foo.com`.
      Hence, this change fails for *all* headers where the initial line begins
      with a space.
      
      Updates #22464
      
      Change-Id: I68d3d190489c350b0bc1549735bf6593fe11a94c
      Reviewed-on: https://go-review.googlesource.com/80055
      Run-TryBot: Tom Bergan <tombergan@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      1c69384d
    • rajender's avatar
      encoding/json: remove the word "text" in "JSON text" from package docs. · 671cf92c
      rajender authored
      It was added in CL 79995. It is unnecessarily confusing.
      
      Change-Id: Ib8ff35b9f71b54ff99d2d6e0534c7128e1f4345a
      Reviewed-on: https://go-review.googlesource.com/80035Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      671cf92c