Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just made a fresh Ubuntu install of apache2 and haproxy. Haproxy listens on port 80, apache on 3080, the latter being hidden from outside.

My problem is that when using a folder name without a trailing slash, e.g. apache automatically redirects to the same address with a slash, but also to the incorrect port,!

Apache docs suggest to me that my problem lies with CanonicalName/Port configuration, but any combinations of those do not seem to work. What could I be mis-understanding?

My virtual host:

<VirtualHost *:3080>

    UseCanonicalName On
    UseCanonicalPhysicalPort On

    DirectoryIndex index.php index.html
    DocumentRoot /var/www/main

    <Directory /var/www/main>
        Options -Indexes
        Options -FollowSymLinks
        AllowOverride All

        <Files ~'^\.'>
            Order allow,deny
            Deny from all
            Satisfy all
share|improve this question
up vote 1 down vote accepted

Use neither;

UseCanonicalName Off
UseCanonicalPhysicalPort Off

HAProxy doesn't (normally) mess with the sent Host header, so this configuration should have the generated redirects built with the correct Location header. If this doesn't help, then provide the exact Location header that's being sent in the response?

By the way, your ServerName can be simplified, and probably shouldn't have a port that your vhost isn't listening on:

share|improve this answer
Interesting - that's how I had it originally, before I discovered this issue. But I've reverted to the way it was before and using curl -i I get the correct Location header: What's more is that I do not see anything in the response specifying the incorrect port, while the issue persists! Then I used the Chrome incognito mode, which disables extensions, and the issue disappeared, though manually disabling all extensions didn't have an effect. I'd be almost ready to write it off as unimportant, but revealing internal configuration seems like a security hole. – Bijou Trouvaille Oct 19 '12 at 7:40
@audio.zoom The bad redirects appearing to persist is usually the client browser caching the redirect; if it's working correctly through curl and a cache-free incognito Chrome instance, then you should be in good shape! – Shane Madden Oct 19 '12 at 15:48
Looks like you were right, clearing the browser cache resolved the issue. Still, I don't understand how it came about in the first place. If the initial settings were correct, where did the browser get incorrect information from? – Bijou Trouvaille Oct 21 '12 at 8:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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