http.req.URI.Scheme inside is empty?

3,027 views
Skip to first unread message

Johann Höchtl

unread,
Mar 1, 2012, 5:17:10 AM3/1/12
to golan...@googlegroups.com
When using the DefaultMux, inside ServeHTTP my req.URL.Schema is always empty. I thought it should be set to "http" according to the documentation
http://tip.golang.org/pkg/net/url/#URL

BTW: Is this the right point to bring in such issues or directly on code.google.com?

- Johann

David Symonds

unread,
Mar 1, 2012, 5:37:17 AM3/1/12
to Johann Höchtl, golan...@googlegroups.com
On Thu, Mar 1, 2012 at 9:17 PM, Johann Höchtl <johann....@gmail.com> wrote:

> When using the DefaultMux, inside ServeHTTP my req.URL.Schema is always
> empty. I thought it should be set to "http" according to the documentation
> http://tip.golang.org/pkg/net/url/#URL

The docs in net/http don't spell it out, but req.URL is constructed by
parsing the Request-URI on the first line of the HTTP request. That
typically looks something like
GET /foo.html HTTP/1.0
which is, of course, a rather limited URL. It has no schema, host,
port, query or fragment, which is why those things won't appear in
req.URL.


Dave.

Johann Höchtl

unread,
Mar 1, 2012, 6:06:31 AM3/1/12
to golan...@googlegroups.com, Johann Höchtl

 but req.URL is constructed by parsing the Request-URI on the first line of the HTTP request. That

typically looks something like
  GET /foo.html HTTP/1.0
which is, of course, a rather limited URL. It has no schema, host,
port, query or fragment, which is why those things won't appear in
req.URL.

Thank you, that's why I am asking here before. I thought I can use the URL.Schema to programmatically assemble a redirect handler without knowing if I have to use http or https.

Johann

Dave.

Andrew Gerrand

unread,
Mar 1, 2012, 5:54:10 PM3/1/12
to Johann Höchtl, golan...@googlegroups.com

You can test if a given *http.Request (req) is https connection like so:

isHTTPS := req.TLS != nil

Andrew

ern...@kramphub.com

unread,
May 24, 2018, 8:35:07 AM5/24/18
to golang-nuts
if your service is behind some TLS terminating hop then you could also inspect the X-Forwarded-Proto header if available.
Reply all
Reply to author
Forward
0 new messages