Using `httputil.NewSingleHostReverseProxy` results in malformed HTTP headers about spdy HOT 8 CLOSED

Could you give some more details?

• What headers did you get when you used http.ListenAndServeTLS?
• Where are these headers being printed from?

Thanks

from spdy.

Reverse-proxied headers sent to www.google.com when using http.ListenAndServeTLS:

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=0
X-Forwarded-For: 127.0.0.1
Host: www.google.com

I'm getting the headers by using Charles as a reverse-proxy to www.google.com, but I've been able to reproduce using a simple HTTP server that prints out the headers, too.

from spdy.

As I understand it, the main issue is the difference between :host and Host. I'll look into why this is happening. It's also odd that the X-Forwarded-For header is different, but that's not set by my library, so I think that's just an oddity of SpdyLay.

Is there something else I'm missing?

from spdy.

Ah, sorry, I used Chrome because SpdyLay doesn't support regular HTTPS connections (it's a SPDY debugging tool: https://github.com/tatsuhiro-t/spdylay). Trying again with curl works:

$ curl https://localhost:5005/
GET / HTTP/1.1
User-Agent: curl/7.30.0
Accept: */*
X-Forwarded-For: ::1
Accept-Encoding: gzip
Host: www.google.com

My understanding is that, for some reason, the lines that start with ": " aren't actually supposed to be there...?

from spdy.

Those are headers new to SPDY. The :host, :method, :path, :scheme, and :version headers must be included in SPDY requests, since they build up the data that would be in an HTTP request line (GET / HTTP/1.1).

All ok?

from spdy.

Oh, I understand now. So, it's sending SPDY headers to the HTTP backend set up in httputil.NewSingleHostReverseProxy... Is that expected behavior?

from spdy.

That's the behavior exhibited by httputil.NewSingleHostReverseProxy. Since it's that code that creates the outward-bound request, it's up to that whether to forward the new headers. However, if I remember correctly, they're still valid HTTP headers, so it shouldn't do any harm to forward them on.

If you don't want to forward the SPDY headers, I suggest writing code similar to the following:

targetURL := url.Parse("http://www.google.com")
reverseProxy := httputil.NewSingleHostReverseProxy(targetURL)
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  for key := range r.Header {
    if strings.HasPrefix(key, ":") {
      r.Header.Del(key)
    }
  }
  reverseProxy.ServeHTTP(w, r)
})
if err = spdy.ListenAndServeTLS(":5005", "cert.pem", "key.pem", nil); err != nil {
  // handle error.
  log.Fatal(err)
}

from spdy.

Ah, I see now. Thanks a lot for your time!

from spdy.