Travis Gere's picture

Hi, I'm new to the forums so please forgive me if I've posted this in the wrong area. We have recently brought up a PHPBB3 appliance in our enterprise.  We have hit a bit of a snag and are hoping to resolve an issue.  If an http request is made without a trailing slash, the server issues a 301 and sends relocate headers appending the trailing slash. This is expected behavior and works great as long as you use the actual host name or IP address of the server. The problem lies in that we have an alias host name pointing to the host.  Referencing the same resource without the trailing slash, causes the server to relocate on HTTPS. 

Everything else works fine, so long as you use fully qualified URLs'.  Is anyone familiar with the Turnkey Linux appliances, especially the PHPBB3 appliance and default Apache configs that might shed some light on why we are seeing this issue?  Ideas on how to resolve?  I can provide more detail if there is interest in helping me resolve this and thanks in advance for your time.  By the way, the PHPBB3 appliance is fantastic and much appreciated.

Forum: 
Alon Swartz's picture

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)

Travis Gere's picture

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!


Alon Swartz's picture

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.

Travis Gere's picture

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.


Travis Gere's picture

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!


Alon Swartz's picture

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

Add new comment