How do I hide the port in my URL?

Question

What am I missing? If I go to mysite.com:9999 I get my site, but not mysite.com Obviously the users shouldn't need to type in the port, so what do I need to do? I'm not really trying to hide the port so much as not require the user to type it in the URL. Is this an Apache configuration setting somewhere? Should I be looking at httpd.config, container config or elsewhere? It is a Virtual Host on Apache server. Any suggestions are appreciated.

Edit- the working virtual host blocks in virtualhosts.conf looks like this:

Near the start the virtual host entries are named something like this:

NameVirtualHost *:700 
NameVirtualHost *:710
...
NameVirtualHost *:760

Below the working block for the http version looks like this:

<VirtualHost *:710>
     ServerName webdev.url.com
     ServerAdmin [email protected]

     # Comment out when OC4J instance is down for maintenance:
     <IfModule mod_oc4j.c>
         Oc4jMount 
     </IfModule>

     # Uncomment when OC4J instance is down for maintenance:
     # DocumentRoot "/org/dev"

     # - Restrict 'Cross-Site-Tracking' or XST
     RewriteEngine on
     RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
     RewriteRule .* - [F]

     <IfModule mod_dir.c>
         DirectoryIndex index.jsp
     </IfModule>
         ErrorLog "|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/dev_error_log 440"
             CustomLog "|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/dev_access_log 440" common


     <Location "/pls/dev">
         Order deny,allow
         Deny from all
         Allow from ####internal ip addresses####
     </Location>

 </VirtualHost>

The new one that requires the port to be specified looks like this:

## - for Mobile 
 <VirtualHost *:770>
     ServerName mdev.url.com
     ServerAdmin [email protected]

     # Comment out when OC4J instance is down for maintenance:
     <IfModule mod_oc4j.c>
         Oc4jMount / msitedev
     </IfModule>

     # - Restrict 'Cross-Site-Tracking' or XST
     RewriteEngine on
     RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
     RewriteRule .* - [F]

     <IfModule mod_dir.c>
         DirectoryIndex m.jsp
     </IfModule>

     ErrorLog "|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/mdev_error_log 440"
     CustomLog "|/opt/app/oracle/product/AS10.1.2/Apache/Apache/bin/rotatelogs/logs/mdev_access_log 440" common


    # <Location "/org/dev">
    #     Order deny,allow
    #     Deny from all
    #     Allow from ####
    # </Location>


 </VirtualHost>

Again, I am just trying to figure out if something here is suppressing the need to enter the port # (eg. 710) in the URL. Upon examination, there don't appear to be any htaccess files anywhere.

Solution 1

Here is the manual for DNS SRV records (RFC 2782) which can be used to change the default port to match what you actually use:

_http._tcp.example.com. IN      SRV 0    5      80   www.example.com.

where next to last field is port, which can have any real value. DNS SRV records can redefine default http port for domain or only for (some) hosts inside domain

Solution 2

When you type the URL in a web browser, http://www.foo.com, it will always attempt to connect on port 80.

It's not so much that the port is being hidden, but rather that it's being assumed, since port 80 is the default for HTTP requests.

Along the same line, if you browse to https://www.foo.com, it will always attempt to connect on port 443 unless you specify another port (https://www.foo.com:8080). Port 443 is the default port for SSL/TLS requests.

Unless you have a compelling reason (because for example if you are running 2 webservices [e.g. Apache and IIS] at the same time on the machine), it might be best to simply change your new virtual host to port 80. Snooping a bit, I saw on SO that you asked a similar question. If you're trying to redirect mobile clients to a different site (or your app, for example), you can user mod_rewrite based on the user-agent.

For example:

<VirtualHost *:80>
DocumentRoot /www/mainwebsite
ServerName www.foo.com 
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera mobile|palmos|webos" [NC]
RewriteRule ^$ http://m.foo.com/ [L,R=302]

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/mobileapp
ServerName m.foo.com
# You might check for the USER_AGENT here and redirect to the main site if not found
</VirtualHost>

It's late and the above may be a bit off -- if this is helpful to you, perhaps someone can edit it to be more correct.

Solution 3

The HTTP protocol uses port 80 by default. If you configure your web server to use a nonstandard port, then the port needs to be specified in the URL. There's no way to hide that.

In Apache, you can set the listening port in httpd.conf, e.g.:

Listen 127.0.0.1:80

This can however be overridden in the vhost config, e.g.:

<VirtualHost *:80>

Solution 4

I only now realize that I never posted the specific answer to my issue.

In the end we needed to add details to webcache.xml to allow the URL to work without a port specified in the URL.

View more solutions

Comments

[Dallas]

It is already doing it for other virtual hosts on the same box, but I don't know where to look, or how it's done.

[Dallas]

We are specifying port in both the Listen and in the VirtualHost. I didn't realize it was overriding it. I just assumed it had to be specified in both.

[Lèse majesté]

@Dallas: it typically is specified in both; just that if what you specify in your VirtualHost directive is different from the Listen directive, then the VirtualHost directive's settings will be followed for that vhost.

[Dallas]

virtualhosts.conf is where everything appears to be but I don't see anything that appears to be hiding the ports used.

[Dallas]

Each <VirtualHost> block has an Oc4jMount, a RewriteCond %{REQUEST_METHOD) ^(TRACE/TRACK) and RewriteRule .* - [F] . Perhaps it's one of these?

[Lèse majesté]

@Dallas: It would be in the <VirtualHost> directive declaration like the example in my answer.

[Dallas]

Yes, each one has the ports declared <VirtualHost*:Port#> ServerName... ServerAdmin... RewriteEngine On... RewriteOptions inherit... ErrorLog /logs/error_log </VirtualHost> block for each, but I don't see anything different between the existing ones (which don't require the port to be typed in) and the new one we are trying to create (which does). There must be something somewhere else.

[Dallas]

As far as the port, there are already several other Virtual Hosts on the same box, all using ports other than 80 or 443, and we don't have to specify ports in the URL. We do have the redirect handled already, but thanks for the suggestion. As an aside I have noticed that if you go for .*mobile*android|android*mobile.* it avoids the tablets. We are designing so that the mobile will look decent on tablets, but we decided there is no reason to automatically redirect them or the ipad when the main site is sufficient, and they can always choose it via links back and forth.

[Kanishka Choudhury]

@dallas Can you check for an .htaccess file in the root of some of the virtual hosts that are working? Will consider this a bit more after lunch.

[Dallas]

I can check in the morning. When we were first looking at how to do the redirect, doing it with the .htaccess file was suggested. I looked around and didn't see an existing one. I didn't really know where I was supposed to be looking at the time though. When you say root, you mean the place were the config files for that VH sit, or the DocumentRoot? I didn't see one in the DocumentRoot for the main site dev region that is working.

[Kanishka Choudhury]

In order to redirect foo.com to foo.com:9999, I can't think of a way to redirect a request from port 80 to another port without there being a VirtualHost on port 80 at least "listening" for requests. If an .htaccess file is somehow handling the redirect, there would still have to be something on foo.com listening on port 80. The .htaccess file would be in the DocumentRoot of the VirtualHost listening on port 80. Do you think you could paste a <code> segment in your above question (edit the question) from one of the hosts that is working? Thinking... mod_proxy might be involved, too.

[Kanishka Choudhury]

@LazyBadger So in order to verify whether if this is in fact how this is being done with their existing hosts, we'd need to see the Zone File?

[Lazy Badger]

@Nathan yes. Or dig relevant records

[Kanishka Choudhury]

That really is very neat! Thanks Lazy Badger! I'd noticed SRV records before, but hadn't really considered how I might use them. You know, I did STFW before I tried to answer, but I must not have searched using the right terms.