PHPBB3 Appliance redirects to HTTPS on requests without the trailing slash (SOLVED)

What do you mean by "we have an alias host name pointing to the host"? Can you elaborate on that as it is most probably the cause of the problem, and what you are trying to accomplish.

The more details and code snippets you can provide will help find the cause and possibly provide a workaround (or a better solution)

Hi Alon, thanks again for your response and help investigating this issue.  We have not really made in changes to the default configuration for phpBB or Apache. I checked our board configuration and we have the server protocol set explicitly to "http" and cookie secure is set to disabled.  When I captured the headers above, I was not logged into phpBB, however the same issue occurs if we create a directory outside of the phpBB installation all together, for example, /usr/share/phpbb3/wwww/foo.  Foo or Foo/ will work fine directly on the host, but not using the alias. Which brings us to your question about how the alias works.  I'm on the web development end with only a basic understanding of how it all works, so here goes.

Our app servers have a fixed IP address and a DNS entry on our internal network. This address is only accessible while physically connected to our network or via a VPN connection.  Our network admins then create a fixed IP with a publicly broadcast IP address and a corresponding DNS entry, this acts as a virtual IP that we use to advertise our application on. Next an F5 load balancer is used as a proxy which sits between our app servers and the world, and accepts all traffic for them. There are actually a couple other aliases on different parts of the network that the load balancer uses for redundancy as well as intelligent traffic routing which all point to our app server. So we can reach the server using multiple virtual host names.  

What we have learned is that any traffic which originates through the F5 and/or any of the virtual aliases will do the redirect to https.  Any requests initiated directly on the server do not. We have reported our observations to the network admins.  And while we remain hopeful that they may find a solution on their end, we must rule out there is any possibility that the issue lies with our application server.  So please let me know if this additional information gives you thoughts for other things we might check for. 

Per the last part of your message, I did try a few different mod-rewrite directives in a test directory with an .htaccess file which should append a trailing slash to any request that does not contain one.  No luck on that, seems produce the same behavior regardless.

What configurations changes (if any) have you made in phpBB / apache?

When performing the above tests, where you logged in? Does it make a difference?

I'm not sure if the cookie has anything to do with it, but you'll notice that they are completely different. In phpBB there is "security setting" called "Server Protocol" with the following explanation:

This is used as the server protocol if these settings are forced.
If empty or not forced the protocol is determined by the cookie secure
settings (http:// or https://).

And this is what it says about secure cookies:

If your server is running via SSL set this to enabled else leave as
disabled. Having this enabled and not running via SSL will result in
server errors during redirects.

I googled a little and couldn't find any hits describing your situation, so my initial thoughts are possibly a misconfiguration with the alias.

Could you explain the "alias" configuration in more detail? How does it work? Does the alias act differently if the connection is over SSL?

A possible workaround (not a solution) would be to direct apache to rewrite URI's that don't have a trailing slash to add one on before passing the request to phpbb3. This might have side effects though, but could be a temp solution until you find the real culprit.

Alon, thanks for your reply, our Turnkey has a fixed address in our internal 10 net. To expose the server to users outside of our organization, the network admins have created an alias to the server with a world accessible IP address and then forward all http requests to port 80 on our internal host.  This seems to work fine, mostly.  However if a requested resource using the alias does not contain a trailing slash , then the turnkey issues a 301 and redirects over to https on 443. Requests withouth a trailing slash work fine from the internal IP, hostname or localhost host with no problems. Below are http headers which show a sample internal and external request (renamed for simplification) note the location to https on the external request:

Internal request example
http://internal.server/com/2013
GET /2013 HTTP/1.1
Host internal.server.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Cookie style_cookie=null; phpbb3_4jolj_k=; phpbb3_4jolj_u=1;
phpbb3_4jolj_sid=bd5beb2ce403768a12cdcf6dd6a01be1
Response
HTTP/1.1 301 Moved Permanently
Date Thu, 06 Jan 2011 02:41:53 GMT
Server Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g
Location http://internal.server.com/2013/
Content-Length 406
Content-Type text/html; charset=iso-8859-1

External request example
http://external.server.com/2013
GET /2013 HTTP/1.1
Host external.server.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Cookie __utma=182291490.1275320142.1293220158.1293254042.1293576113.4;
__utmz=182291490.1293254042.3.2.utmcsr=internal.server.com|utmccn=(
re
ferral)|utmcmd=referral|utmcct=/
Response
HTTP/1.1 301 Moved Permanently
Date Thu, 06 Jan 2011 02:50:52 GMT
Server Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g
Location https://external.server.com/2013/
Content-Length 406
Content-Type text/html; charset=iso-8859-1

I didn't want to overcomplicate this post, but I can provide additional information about our particular configuration if that would help. Just wondering if you think there are any default configurations that might cause the turnkey to care about the format of the alias requests and respond this way? Possibly a mod-rewrite directive somewhere? Thanks again for your help!

Well it turns out this issue had nothing to do with our appliance and everything to do with our F5.  The network admins were able to resolve the issue on their end.  What I did find helpful for my own sanity was to create a rewrite rule and setup a rewrite log which allowed me to see the 301 and verify the redirects were explicitely set to http.  The response headers my browser was receiving were being transformed to https, which was different than than my log, so it became obvious an external transformation was taking place.  But thanks for listening!

Glad you got to the bottom of it, kuddo's to you and your network admins!