Welcome Guest, Not a member yet? Register   Sign In
Why does URL Helper support unofficial HTTP header REFRESH?
#1

[eluser]ray023[/eluser]
Last week, I composed a long and, IMHO, rather confusing post regarding a Blank Page loading in my application; with no obvious errors logged or displayed. The peculiar thing was that the blank page only occurred on my client's network.

The piece of code that turned out to be the culprit was in the URL helper:

Code:
case 'refresh'    : header("Refresh:0;url=".$uri);

I took CodeIgniter out of the picture and created my own php script that looks as follows:

Code:
<?php
if (headers_sent()) {
  die('cannot send location header (anymore)');
}
else {
  header("Refresh: 0; url=http://www.google.com"); //This does not work
  //header("Location: http://www.google.com"); //This does work
  die();
}
?>

With all things remaining the same, except for the company network, I was able to reproduce this issue.

I did some searching on header refresh to see if I could get a better understanding. As it turns out refresh is not a supported HTTP header.

I did see in the User's Guide that Location can sometimes cause a problem, but, based on my recent experience, Refresh can cause problems as well.

I'm just curious why there is an implementation of Refresh for redirect since it is not officially supported.
#2

[eluser]WanWizard[/eluser]
Refresh (along with Set-Cookie and possibly some other proprietary pseudo-headers) were created by Netscape in the very early days of the internet and have been basically (but not quite) standard since then.
Because just about every browser supports it, Refresh is pretty safe to use -- and commonly is. W3C disapproves of them, and wants you to use meta tags instead.

If you would look at code (for example the firefox source), you'll see that the refresh header calls the same code as the meta refresh tag. With the difference that for a header you don't have to parse the HTML, so I personally perfer a header if possible.

Which begs the question: which browser was being used on this client's network? Or, in case of a corporate network, which security measures (reverse proxies, L7 load balancers, application level firewalls) were in place that could possibly interfere with 'non-standard' HTTP headers?
#3

[eluser]ray023[/eluser]
[quote author="WanWizard" date="1286913113"]...
Which begs the question: which browser was being used on this client's network? Or, in case of a corporate network, which security measures (reverse proxies, L7 load balancers, application level firewalls) were in place that could possibly interfere with 'non-standard' HTTP headers?[/quote]

The browsers in use were IE 8 and FF 3.6. I know this for a fact because I brought in my laptop to demo the latest version and both the stakeholders and myself stared at a blank screen waiting on the application to load. A little embarrassing...but that's just par for the course when it comes to a demo.

I resolved that situation by loading XAMMP and demoing locally.

I don't know much about the corporate network where the issue happened but I will find out what security they've implemented and let you know. I'm very curious myself because it seems like such an odd thing to filter out.

Great explanation btw! Thanks for the quick reply.
#4

[eluser]WanWizard[/eluser]
I assume you tested your application before shipping it to the customer, and that you did that using those browsers. And that you didn't experience the problem, otherwise you wouldn't have given the demo.

Hence my question about the rest of the infrastructure in that company. I had a similar issue at a client where a layer-7 device in the datacenter decided that the HTTP header was malformed (in this case it choked on a very long cookie), and subsequently blocked the traffic. With a blank page as a result. Cisco firewalls with protocol fixup's can have similar nasty side-effects...
#5

[eluser]ray023[/eluser]
[quote author="WanWizard" date="1286919720"]I assume you tested your application before shipping it to the customer, and that you did that using those browsers. And that you didn't experience the problem, otherwise you wouldn't have given the demo.
[/quote]

Absolutely; that's why I walked in to the meeting feeling fairly certain no hiccups would happen.

No big deal. That's why I prepare (or try to prepare) for all scenarios.

Got in touch with the company's technical contact who states the following:
Quote:There aren’t any proxies or load balancers in place. The only thing that I can think of that could be causing the issues is their firewall. I can try to make some adjustments to the outbound policy to see if we can make it work, if we need to.

There's a tone in the e-mail implying we can try stuff even though we don't really want to.

So since I'm the only one interested in it at this point, I'm just going to drop it.

The workaround for me is fine. I just have to bear in mind to avoid using redirect refresh and be mindful of extensions that might use it as well (e.g. ion_auth)

Thanks so much for your input!




Theme © iAndrew 2016 - Forum software by © MyBB