page redirect using HEADER weird results

pbrama

I have, at least what I consider, a weird problem....

At the top of a PHP page, is a batch of PHP code that does some specialized database processing. A few lines into that code, we do a comparison to see if the remainder of the page is to be processed or if we should go back to the home page.

The code is something like this....

**** LOAD SOME VARIABLES AND PRESET SOME SETTINGS CODE HERE ****

// Make sure we are in ADMIN mode based on $admin variable being true
if ($admin==false) {
     header("Location: ./");
}

**** CONTINUE WITH THIS PAGE ****

What is SUPPOSE to happen:
- if $admin==true, the the page processes and remains on this page.
- if $admin==false, then the page does NOT process and immediately goes to the home page

Here is the "weird" portion:
- no matter what $admin is, the page processes AND goes to the home page

If I put // before the actual header line

if ($admin==false) {
     // header("Location: ./");
}

It still does the same exact thing... and processes the page and goes to the home page

If I physically remove the header line

if ($admin==false) {

}

Then the page processes and STAYS on this page.

I've even tried this...

**** LOAD SOME VARIABLES AND PRESET SOME SETTINGS CODE HERE ****

header("Location: ./");

**** CONTINUE WITH THIS PAGE ****

And the page STILL processes THEN goes to the home page.

What am I missing here? I need this page to stop execution at the if loop and leave the page immediately if the if statement is met.

Weedpacket

Calling [man]header[/man] does not stop further processing of the page. [font=monospace]Location:…[/font] should be followed by [man]exit[/man] unless there is further processing you want to do.

As for the page it ends up on: If your request was for [noparse]http://www.example.com/path/to/some/page[/noparse] then the location you give in your URI is [noparse]http://www.example.com/path/to/some/[/noparse]. This may or may not be what you want, but you can avoid possible confusion by using an absolute URI instead (i.e., if your home page is at [noparse]http://www.example.com/[/noparse] then redirect them to [noparse]http://www.example.com/[/noparse]). If you really want to use a relative URI to go to the path root, then that's [font=monospace]/[/font] (contents of the page's [font=monospace]<base>[/font] element, if any, notwithstanding).

pbrama

That makes sense. I had a feeling it was something like that. These pages were converted from ASP and that was an immediate redirect. Thank You

NogDog

In fact, I think the HTTP spec says that a Location header should always be a fully qualified URI, though in practice you can get away with a relative one in most browsers.

dalecosp

NogDog;11046547 wrote:
In fact, I think the HTTP spec says that a Location header should always be a fully qualified URI, though in practice you can get away with a relative one in most browsers.

It does, indeed, specify that.

schwim

I had no idea about the header requiring a full URI. I've got a lot of changes to make!

Weedpacket

dalecosp wrote:
It does, indeed, specify that.

RFC2616 does specify an absolute URL. Late yesterday though (I think it was late - some people told me it was really early but I don't think they were talking about yesterday) I found I found that it has been obsoleted by six RFCs starting at RFC7230. What's interesting there is that the "absolute" requirement no longer exists, and is now explicitly allowed to be relative (to be resolved against the URI of the request).

RFC7231, §7.1.2 wrote:
The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).

That's a downside of the immutability of RFC documents: they can't tell you themselves if they've been obsoleted.

Important thing to note: Relative-URI redirections are made relative to the request URI, not to the URI of the page the user (might) be making the request from (the referring URI). I actually got that wrong when I originally replied (I've gone back and fixed it to avoid future confusion).