2

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. example.com/some/folder apache automatically redirects to the same address with a slash, but also to the incorrect port, example.com:3080/some/folder/!

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>

    ServerName http://example.com:80
    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
        </Files>
    </Directory>
</VirtualHost>
Improve this question
0

1 Answer 1

Reset to default
1

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:

ServerName example.com
Improve this answer
3
  • 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: http://example.com/some/folder/. 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, 2012 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, 2012 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, 2012 at 8:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .