RFC 7233, section 4.4 says:
>>>
For byte ranges, failing to overlap the current extent means that the
first-byte-pos of all of the byte-range-spec values were greater than the
current length of the selected representation. When this status code is
generated in response to a byte-range request, the sender SHOULD generate a
Content-Range header field specifying the current length of the selected
representation
<<<
Thus, we should send the Content-Range only if none of the ranges
overlap.
Fixes#15798.
Change-Id: Ic9a3e1b3a8730398b4bdff877a8f2fd2e30149e3
Reviewed-on: https://go-review.googlesource.com/24212
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Certain browsers (Chrome 53, Safari 9.1.2, Firefox 46) won't correctly
follow a directory listing's links if the file name begins with a run
of characters then a colon, e.g. "foo:bar". Probably mistaking it for
a URI. However, they are happy to follow "./foo:bar", so this change
prepends "./" to all link hrefs in the directory listing of
FileServer.
Change-Id: I60ee8e1ebac73cbd3a3ac0f23e80fdf52e3dc352
Reviewed-on: https://go-review.googlesource.com/27440
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
s390x doesn't have sendfile64 so apply the same fix as MIPS
(eebf7d27) and just use sendfile.
Change-Id: If8fe2e974ed44a9883282430157c3545d5bd04bd
Reviewed-on: https://go-review.googlesource.com/21892
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Martin Lenord pointed out that bad patterns have emerged in online
examples of how to use ServeFile, where people pass r.URL.Path[1:] to
ServeFile. This is unsafe. Document that it's unsafe, and add some
protections.
Fixes#14110
Change-Id: Ifeaa15534b2b3e46d3a8137be66748afa8fcd634
Reviewed-on: https://go-review.googlesource.com/18939
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
If we try to reuse a connection that the server is in the process of
closing, we may end up successfully writing out our request (or a
portion of our request) only to find a connection error when we try to
read from (or finish writing to) the socket. This manifests as an EOF
returned from the Transport's RoundTrip.
The issue, among others, is described in #4677.
This change follows some of the Chromium guidelines for retrying
idempotent requests only when the connection has been already been used
successfully and no header data has yet been received for the response.
As part of this change, an unexported error was defined for
errMissingHost, which was previously defined inline. errMissingHost is
the only non-network error returned from a Request's Write() method.
Additionally, this breaks TestLinuxSendfile because its test server
explicitly triggers the type of scenario this change is meant to retry
on. Because that test server stops accepting conns on the test listener
before the retry, the test would time out. To fix this, the test was
altered to use a non-idempotent test type (POST).
Change-Id: I1ca630b944f0ed7ec1d3d46056a50fb959481a16
Reviewed-on: https://go-review.googlesource.com/3210
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
mips64 strace doesn't support sendfile64 and will error out if we
specify that with `-e trace='. So we use sendfile for mips64 here.
Change-Id: If5e2bb39866ca3a77dcc40e4db338ba486921d89
Reviewed-on: https://go-review.googlesource.com/14455
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was generating the wrong error message, always defaulting to "500
Internal Server Error", since the err variable used was always nil.
Fixes#12991
Change-Id: I94b0e516409c131ff3b878bcb91e65f0259ff077
Reviewed-on: https://go-review.googlesource.com/16060
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously all errors were 404 errors, even if the real error had
nothing to do with a file being non-existent.
Fixes#10283
Change-Id: I5b08b471a9064c347510cfcf8557373704eef7c0
Reviewed-on: https://go-review.googlesource.com/9200
Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com>
ServeContent ignored zero time.Time{} values when generating
Last-Modified response headers and checking If-Modified-Since request
headers. Do the same for a time.Time representing the Unix epoch zero
value, as this is a common bogus value. Callers who really want to
send that value (incredibly unlikely) can add a nanosecond to it and
it will be truncated to second granularity anyway.
Fixes#9842
Change-Id: I69f697bfc4017404a92a34e3fe57e2711c1e299d
Reviewed-on: https://go-review.googlesource.com/7915
Reviewed-by: David Symonds <dsymonds@golang.org>
Given a file of size N, a request for "Range: bytes=N-*" should
return a 416 [1]. Currently, it returns a 206 and a body of 0
bytes, with the illegal Content-Range of "bytes N-(N-1)/N" [2].
[1]: RFC 7233, sec 2.1: "If a valid byte-range-set includes at least one
byte-range-spec with a first-byte-pos that is less than the current
length of the representation, [...]". sec 3.1: "If all of the
preconditions are true, the server supports the Range header field for
the target resource, and the specified range(s) are invalid or
unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable)
response."
[2]: RFC 7233, sec 4.2: "A Content-Range field value is invalid if it
contains a byte-range-resp that has a last-byte-pos value less than its
first-byte-pos value, [...]"
Fixes#8988
Change-Id: If3e1134e7815f5d361efea01873b29aafe3de817
Reviewed-on: https://go-review.googlesource.com/1862
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
