Is Port Number Required in HTTP "Host" Header Parameter?

Question

Say I make an HTTP request to: foosite.com but the port I actually send the request to is 6103 and I DON'T put that port in the Host header for example:

GET /barpage HTTP/1.1
Host: foosite.com
Method: GET

Should http server then recognize that I'm trying to talk to it on port 6103? Or since it was omitted in the request header am I gambling on if the server actually recognizes this?

I ask that question to say this: I've found that browsers, at least firefox + chrome, put the port in the Host header. But the Java app I'm using does not. And when the port is not passed in the Host the server responds back thinking I'm on port 80. So who do I need to badger? The server operator, or the Java programmer?

Essentiality

6103 is one weird port for HTTP – Amative

I agree with @NullUserException. HTTP defaults to port 80, so I'd get with your Java developer to ensure they include the non-standard port in their call(s). – Sasin

It's for basically an API service for real estate listings. Specifically RETS rets.org/documentation. The companies that provide RETS for multiple listing services tend to either give them subdomains or ports off their main domain so like socalmls.someretscompany.com or someretscompany.com:6111. Don't ask my why they use ports. I just work here ;) – Essentiality

YES, the server can use the actual port number that was connected to. In fact, to be reusable, the server MUST do so. To do otherwise is a security error (ex: firewall blocks port 81 except for trusted clients; untrusted client connects to port 80 and sends Host: 1.2.3.4:81). The server can detect the port number in multiple ways - the simplest is probably to check which listening socket it accept()'d the incoming connection from... – Floaty

Answer 1

See section 14.23 of the HTTP spec which specifies that the port # should be included if it's not the default port (80 for HTTP, 443 for HTTPS).

Carvajal

Yeah I read that in the RFC as well. I probably should have noted that. I was hoping for someone to say something knowledgeable in the sense of knowing specifically how certain web servers and web app frameworks react to this kind of request like: "Some web servers / app frameworks handle it, but X and Y don't" etc etc. Ultimately I expected to just accept what the RFC had to say, but I'm going to give this question maybe a day before I give up. – Essentiality

Thank you, now I know this is a bug in IE11 mobile! – Heaves

It should be clarified that the RFC says if its not the default port for the protocol. and give the example if HTTP it should be 80. If its HTTPS, the default would be 443 (i.e. on a https request, a port of 443 may not be included.) – Provide

Answer 2

UPDATED for modern day browsers:

Browsers (and curl) will add the port only when it is not the standard port, as required by the HTTP spec and noted in @superfell's answer.

Browsers this day (2013), will actually strip the port from the Host Header when the port is the standard (http port 80, https port 443). Some clients, which use their own method, like the Baidu Spider, include the port number even when the port is 80.

Whether this is proper or not, I don't know. The spec doesn't say whether it's OK or not to include the port number when the port used IS the default.

To answer your comment, servers will do whatever they need to do to comply with the spec, and the spec suggests only the cases WHEN it's needed. Because of this, I feel It's not really a question of how the server deals with it - it's more how the client issues the request: includes the port number in the Host Header, or not.

Kob

the spec clearly says that it's ok to include the port number (the naming authority includes the port), i.e. the port number is required, unless it's the default for the service. – Munitions

I'ld like to add to this: I've noticed that some proxies, or web servers acting as reverse proxies may rewrite this. A common configuration for fronting application servers using NGINX is to set the host header and :. when running in this configuration, the end result is a combination of what the browser does, and what the various web proxies, WAF, and web servers may do to the header before it is received by any application code – Provide

I noticed that if you load http://www.facebook.com:80/example and include the :80 in the host header, it redirects you to https://www.facebook.com:80/example which obviously doesn't work. If your client not doing this breaks Facebook, you'd better do it. – Imparipinnate

Answer 3

RFC2616 states that

A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for http://www.w3.org/pub/WWW/ would properly include:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

This means that https://example.com would not need a trailing port as well since the default port is known for https. I have checked the HTTP requests from Firefox, Chrome and Edge and found that none of them added the port number for the host header when the domain protocole was https. For sure the port number is added when the port number was also added to the URL. The following screenshots below come from Google chrome

Bowfin

Answer 4

Sample headers of an actual request to a hopefully non existent server 'http://myhost.com:3003/content/page.htm'

Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US;q=0.9,en;q=0.8,nb;q=0.7,de;q=0.6
Connection: keep-alive
Host: myhost.com:3244
Referer: http://myhost.com:3244/content/page.htm

The RFC https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html requires some training to read.

Section 14:24 not so easy to translate all elements to the simple reality:

Host = "Host" ":" host [ ":" port ] ;

Drumfish

Answer 5

Host Header Syntax:

Host: :

if its not default than put port after host:

Host: example.com:1337

Hoye