Comment 2:

Huh? why would you request set that header on a request? That's a response header when
the request contains multiple ranges, both of which are already supported.
If I interpret your bug report literally, http://play.golang.org/p/obgPztwBL6 , then I
see that it works fine.

Status changed to WaitingForReply.

Comment 3:

Sorry, I meant response.
http://play.golang.org/p/fmf6BDdMAM

Comment 4:

Crazy. The http package shouldn't even be interpreting that.  That looks like some
ancient code, probably put there defensively.
Will fix (delete).

Labels changed: added go1.1, removed priority-triage, go1.1maybe.

Owner changed to @bradfitz.

Status changed to Accepted.

Comment 5:

I wonder if it's there because it's hard to find the correct content length on
multipart/byteranges bodies. Do they have Content-Length headers, or do they just rely
on their separators to show where the end of the body is?

Comment 6:

Actually, Apache and our server send the correct Content-Length, and so Go's HTTP client
works fine on them.
You only get this error message if it's not marked as chunked, there's no
Content-Length, and it's not a "Connection: close" response.
What server sends a HTTP/1.1 multipart/byteranges response without Close,
Content-Length, or Transfer-Encoding: chunked?
Reading RFC 2616 more, I can't find evidence to suggest this is even legal.

Labels changed: added go1.1maybe, removed go1.1.

Status changed to WaitingForReply.

Comment 7:

Oh, actually... we don't even handle Connection: close responses:
Works: http://play.golang.org/p/NZQQFUbyXZ
Doesn't: http://play.golang.org/p/eGBABAMLOR

Status changed to Accepted.

Comment 8:

I don't remember the exact URL, but it is one of the servers for Windows Updates.

Comment 9:

https://golang.org/cl/7435046

Status changed to Started.

Comment 10:

This issue was closed by revision 0bc38b7.

Status changed to Fixed.

Comment 11:

Now I've confirmed that the specific issue I was having with Windows update has been
fixed.