<p dir="auto">by <strong>jonnosan</strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
1. grab current version of go with "hg clone -r release
<a href="https://go.googlecode.com/hg/" rel="nofollow">https://go.googlecode.com/hg/</a> go"
2. cd go
3. ./all.bash

What is the expected output?
###########
1 known bugs; 0 unexpected bugs

---
Installed Go for darwin/amd64 in /Users/jonnosan/src/go.
Installed commands in /Users/jonnosan/src/go/bin.
The compiler is 6g.
###########

What do you see instead?
###########
gopack grc _test/net.a _gotest_.6 
--- FAIL: net.TestGoogleSRV
    failed: lookup _xmpp-server._tcp.google.com. on 10.5.1.1:53: no answer from server
    no results
FAIL
###########


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
OS X 10.6.5

Which revision are you using?  (hg identify)
a7800e20064a+ tip

Please provide any additional information below.

It looks like there are two tests that depend on a the host
_xmpp-server._tcp.google.com. resolving, and this hostname is not currently resolving,
which means the test fails, and thus installation of go is aborted. commenting out the
tests using this hostname in pkg/net/srv_test.go and pkg/net/dns_nametest.go allowed
installation to complete.</pre>
<p dir="auto">by <strong>robryk</strong>:</p>
<pre class="notranslate">When the current client follows a redirect, all subsequent requests are sent without any
of the headers sent on the initial request. The following program demonstrates this
behaviour:

<a href="http://play.golang.org/p/AExnEZNwv8" rel="nofollow">http://play.golang.org/p/AExnEZNwv8</a>

The header which gets printed on stdout is empty; I'd expect it to be equal to
"bytes=0-1", the value set in the original request.

This is counterintuitive and makes the Request.Header useless if a redirect can occur.
It seems that one must either make a custom transport wrapper that adds headers and
create a client on top of that, or use an undocumented feature of CheckRedirect, namely
that the request passed is going to be actually sent, so it can modify it before that.

I'm not sure what resolution I'd expect. My main problem is that this behaviour confused
me, and I can't see an elegant way of setting eg. a Range header on subsequent requests
-- creating a new transport wrapper for every request seems weird, even if it's mostly
cost-free.</pre>