Port 80 being inserted into HTTPS URLs

Recently we’ve installed Omeka S for the first time. We have the peculiar problem of Omeka S inserting port 80 into links that are specifically HTTPS. So, for example, we might have a link on the Omeka site that looks like this:

https://liblamp-dev.uwm.edu:80/omeka-s/files/original/2eb754132fe9ae1c31d3b1d901c3e6c2109360b5.jpg

This doesn’t happen for every link, but it does for things like the password reset email and even links to file derivatives. Removing port 80 makes the links work. Does anyone have any suggestions as to how to fix this or why it may be happening? Thanks.

Do you know if your server is running behind a proxy? I’m guessing that it is, because that’ s the basic situation I know of where something like this could happen.

We’re using Apache and PHP-FPM using sockets. The VirtualHosts file looks like this:

<VirtualHost *:443>
  ServerName liblamp-dev.uwm.edu
  DocumentRoot /var/www/html/
  ErrorLog logs/web-error_log
  CustomLog logs/web-access_log common
  LogLevel debug
<Directory "/var/www/html">
    DirectoryIndex index.php
    Options -Indexes
    AllowOverride All
    Require all granted
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php-fpm/php81.sock|fcgi://liblamp-dev2.ad.uwm.edu"
    </FilesMatch>
</Directory>

#fixes mixed content issue with omeka
<IfModule mod_env.c>
   SetEnv HTTPS on
</IfModule>
</VirtualHost>

What I think is happening is that your whole server is behind a separate proxy, which is doing the HTTPS handling and connecting to your backend server with plain HTTP. This isn’t an uncommon setup in universities lately, it seems.

I see from what you’ve shown here that you’re kind of “cheating” and faking HTTPS being on always with that SetEnv directive, and that’s what’s leading to the mismatch here: Omeka S sees that you have HTTPS on so generates https:// URLs, but it also sees that the actual connection came over port 80. You have a HTTPS VirtualHost shown there, but I assume you also have an HTTP one, and that’s probably what’s actually being used.

If this is the situation you have, the “right” way to fix this for Omeka S is to set the header X-Forwarded-Proto to https: Omeka S contains code that checks for that header and will set the scheme and port correctly even if the request is actually coming in as HTTP.

If you do have a university-provided proxy in front of your server, you may be able to ask them to set this header for requests coming to your server. If that’s difficult to achieve, you can “fake” it in your own Apache config similar to what you’ve done here (you then shouldn’t need the SetEnv workaround):

RequestHeader set X-Forwarded-Proto https

Yep, that fixed it! Thank you!