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 admin@url.com

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

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

     # - Restrict 'Cross-Site-Tracking' or XST
     RewriteEngine on
     RewriteRule .* - [F]

     <IfModule mod_dir.c>
         DirectoryIndex index.jsp
         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####


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

## - for Mobile 
 <VirtualHost *:770>
     ServerName mdev.url.com
     ServerAdmin admin@url.com

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

     # - Restrict 'Cross-Site-Tracking' or XST
     RewriteEngine on
     RewriteRule .* - [F]

     <IfModule mod_dir.c>
         DirectoryIndex m.jsp

     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>


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.

  • Do you have anything listening on port 80? Maybe something other than <VirtualHost *:80>? Something like <VirtualHost 123.456.78.9:80>? As an aside (and I don't mean to push you off on another SE), is this becoming more appropriate for ServerFault? – Nathan Dec 12 '11 at 14:27
  • If you think that's more appropriate... is there a way to migrate the question over, instead of recreating it? At one point there was a Listen #.#.#.#:80 and NameVirtualHost#.#.#.#:80 block, but it is commented out now. – Dallas Dec 12 '11 at 16:07
  • I do see that in default-web-site.xml for that container it has something like: <web-site port="710" protocol="ajp13" display-name="OracleAS Java Web Site"> <frontend host="dev.url.com" port="80" /> <default-web-app application="main" name="main" /> – Dallas Dec 12 '11 at 17:15
  • Confirmed that there is no .htaccess file for sure. – Dallas Dec 12 '11 at 19:32
  • Do you see the answer from LazyBadger below? Is it possible for you to look at the Zone File or dig one of the domains that is working to see if there is a SRV statement? – Nathan Dec 13 '11 at 0:35

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

  • @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? – Nathan Dec 12 '11 at 21:36
  • @Nathan yes. Or dig relevant records – Lazy Badger Dec 12 '11 at 21:39
  • 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. – Nathan Dec 13 '11 at 0:39
  • 1
    This answer is unfortunately wrong as far as I can tell. SRV records cannot be used with the HTTP protocol, or even if it's technically not a protocol violation, it has zero browser support. stackoverflow.com/a/9063595/2234742 – Maximillian Laumeister Jun 17 '20 at 22:44

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 *: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

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.

  • 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. – Dallas Dec 11 '11 at 15:59
  • @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. – Nathan Dec 11 '11 at 18:30
  • 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. – Dallas Dec 11 '11 at 18:52
  • 1
    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. – Nathan Dec 11 '11 at 19:44

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.:


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

<VirtualHost *:80>
  • 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 Dec 11 '11 at 4:22
  • @Dallas: your vhost configurations can be specified in httpd.conf or in a separate conf file (usually httpd-vhosts.conf in the extra configs directory). Just do a search in your config directory for '9999' and you should be able to find where it's specifying that port number. Then just replace it with 80, and you should be good to go. – Lèse majesté Dec 11 '11 at 4:26
  • 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. – Dallas Dec 11 '11 at 4:27
  • @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. – Lèse majesté Dec 11 '11 at 4:29
  • virtualhosts.conf is where everything appears to be but I don't see anything that appears to be hiding the ports used. – Dallas Dec 11 '11 at 4:31

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.