sessions and redirecting in opera

Hello all,

I have posted a similar question in comp.lang.php in the past, but haven't
had any response to it then. I kinda swept the problem under the rug since
then. But I would really like to resolve this issue once and for all now.

The problem might be PHP related but since I only develop applications using
PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
crosspost to comp.lang.php and alt.www.webmaster. I assume the majority of
frequent contributors of these groups have dealt with developing session
management also, so I'm kind of hoping your experience in this field might
resolve this issue.

The problem is the following:

User profiles on the site I'm developing will be publically available
through:

http://www.example.com/profile/view/

A users own profile (when logged in) will be available through:

http://www.example.com/profile/view/ or
http://www.example.com/profile/ (which will redirect to last url)

So when an anonymous user visits one of these last two pages, the requested
page is stored as a referer in a session and the user is redirected to

http://www.example.com/user/login/

where the user is prompted to login.

On succes it gets redirected to the stored referer url again. A pretty
common procedure I would assume.

This works fine on either IE or Firefox (windows). But in Opera I get
multiple sessions created in the database of which one *does* contains a
userId but Opera redirects back to the login page again.

Only when I manually enter the target url I do get to see the logged in
users profile page.

My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page to
serve. So, after much testing, I thought it might have something to do with
Opera's favicon requests.

But after defining an extra RewriteRule

RewriteRule ^(.*)favicon.ico /images/favicon.gif [NC,L]

in my .htaccess file, the problem still persisted.

Are any of you formiliar with this issue?

I understand that this might be difficult to interpret without seeing any
code. But since the code is pretty extensive, and I haven't really narrowed
it down to a particular few lines, I thought I describe the problem without
code first. Maybe somebody has had similar experiences and knows what the
problem could be.

But if you desire to examine some code, I'ld be happy to put some up on a
filesharing server for you to view. (e.g. the session wrapper class and
other relevant code).

Thank you for your time and input.

Cheers.

Re: sessions and redirecting in opera

"amygdala" schreef in bericht
news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl...
> Hello all,



PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
session_write_close().

Re: sessions and redirecting in opera

amygdala wrote:

> The problem might be PHP related but since I only develop applications using
> PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
> crosspost to comp.lang.php and alt.www.webmaster. I assume the majority of
> frequent contributors of these groups have dealt with developing session
> management also, so I'm kind of hoping your experience in this field might
> resolve this issue.

I don't code in PHP. I have written my own session management procedures
in Perl. I will answer based on the assumption that PHP uses cookies to
manage sessions.

> User profiles on the site I'm developing will be publically available
> through:
>
> http://www.example.com/profile/view/
>
> A users own profile (when logged in) will be available through:
>
> http://www.example.com/profile/view/ or
> http://www.example.com/profile/ (which will redirect to last url)
>
> So when an anonymous user visits one of these last two pages, the requested
> page is stored as a referer in a session and the user is redirected to
>
> http://www.example.com/user/login/
>
> where the user is prompted to login.
>
> On succes it gets redirected to the stored referer url again. A pretty
> common procedure I would assume.
>
> This works fine on either IE or Firefox (windows). But in Opera I get
> multiple sessions created in the database of which one *does* contains a
> userId but Opera redirects back to the login page again.

(I realize I haven't snipped very well, but I don't know what to remove
and still keep my comments in context.)

Again, I don't know how PHP manages sessions, but what you are saying
here about Opera seems strange to me. If PHP is using a cookie to store
session information in the browser, then there should only be one
session. One cookie can't have multiple values.

BTW, the browser doesn't create sessions in the database. PHP is doing
that. The browser stores session information in a cookie, which can only
contain one value.

> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page to
> serve.

Why? If you have stored the URL of the page you want to go to in a
cookie, you should be looking for which page to serve in that cookie.

Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
store in the cookie? Again, why? If I have a PHP script at
example.com/user/login, why doesn't that script know its own URL? Why
can't the script at example.com/user/login simply store its own URL in
the cookie?

I may be way off base here, but your approach seems odd to me.

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 17:39:55 +0200, amygdala wrote=
:

> Hello all,
>
> I have posted a similar question in comp.lang.php in the past, but =

> haven't
> had any response to it then. I kinda swept the problem under the rug =

> since
> then. But I would really like to resolve this issue once and for all n=
ow.
>
> The problem might be PHP related but since I only develop applications=
=

> using
> PHP, I'm not a hundred percent sure. Therefor I've taken the liberty t=
o
> crosspost to comp.lang.php and alt.www.webmaster. I assume the majorit=
y =

> of
> frequent contributors of these groups have dealt with developing sessi=
on
> management also, so I'm kind of hoping your experience in this field =

> might
> resolve this issue.
>
> The problem is the following:
>
> User profiles on the site I'm developing will be publically available
> through:
>
> http://www.example.com/profile/view/
>
> A users own profile (when logged in) will be available through:
>
> http://www.example.com/profile/view/ or
> http://www.example.com/profile/ (which will redirect to last url)
>
> So when an anonymous user visits one of these last two pages, the =

> requested
> page is stored as a referer in a session and the user is redirected to=

>
> http://www.example.com/user/login/
>
> where the user is prompted to login.
>
> On succes it gets redirected to the stored referer url again. A pretty=

> common procedure I would assume.
>
> This works fine on either IE or Firefox (windows). But in Opera I get
> multiple sessions created in the database of which one *does* contains=
a
> userId but Opera redirects back to the login page again.
>
> Only when I manually enter the target url I do get to see the logged i=
n
> users profile page.
>
> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which pa=
ge =

> to
> serve. So, after much testing, I thought it might have something to do=
=

> with
> Opera's favicon requests.

Hmm, FF & MSIE equally request that damn thing, shouldn't matter I think=
....

> I understand that this might be difficult to interpret without seeing =
any
> code. But since the code is pretty extensive, and I haven't really =

> narrowed
> it down to a particular few lines, I thought I describe the problem =

> without
> code first. Maybe somebody has had similar experiences and knows what =
the
> problem could be.

It's very hard to say. Are you sure you're not actually using the HTTP =

REFERER header instead of the one stored in a session? It's pretty =

unreliable, and very easy to disabled in Opera, i.e. the server never ge=
ts =

this header. (Don't know wether it's a standard settings, it's a setting=
I =

use nonetheless, and stored under'quick preferences', so easily accessab=
le =

for normal users). Another easily accessed Opera feature is to disable =

redirecting. If you're relying on it to transfer the user to another pag=
e, =

but don't exit your script after the redirect, chances are that in Opera=
=

it might come across as 'the same page again'. So on a redirect, always =
do =

something like:

$target =3D 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click
href=3D"'.$target.'">here if it doesn't work';
exit; //<-----IMPORTANT!

A very easy mistake to make is also differnce in domain (for instance wi=
th =

or without 'www.' in front of it, cookies that are sent vie https aren't=
=

set by http and vice versa).

If that doesn't work, I'd set up a testpage instead of the normal redire=
ct =

to /user/login/, and instead of redirecting, dump the session-id & the =

$_SESSION array, and exit. That might give you some insight in what =

happens.

It could be a path issue for the cookie also though (as /profile & =

/user/login are different, maybe the cookie is set carelessly, and there=
=

are 2 different cookies for the differents paths)... If you use =

LiveHTTPHeaders in FF or Fiddler in MSIE, what do you see as Set-Cookie =
=

statements?

If all fails, I'd appreciate a live example, as I'm quite an Opera-fan, =
=

and I can't let this slide :P

f'upped to comp.lang.php BTW.
-- =

Rik Wasmus

Re: sessions and redirecting in opera

In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
amygdala wrote:
>
>"amygdala" schreef in bericht
>news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl...
>> Hello all,
>
>
>
>PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
>session_write_close().

Why? Are you using framesets? If so, why?

I do something similar on my site, and I use Opera to test. A
user gets a session cookie when first accessing any page on my
site. As long as the $_SESSION array contains no login information,
some content is restricted; any attempts to access that restricted
content go to a login page. As soon as the user logs in, $_SESSION
contains data proving that the user is logged in. $_SESSION also
contains the last page visited and next page requested, at all
times, so it's trivial to direct the user to the proper page after
logging in, using header("Location: http://example.com/xyz.php?a=b");

This works for me in Opera. At *no* time do I attempt to close the
session. That happens only when the user logs off, in which case I
delete the session.

-A

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 18:31:55 +0200, axlq wrote:

> In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
> amygdala wrote:
>>
>> "amygdala" schreef in bericht
>> news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl...
>>> Hello all,
>>
>>
>>
>> PS.: I forgot to mention that, before redirecting, I *do* let PHP
>> perform a
>> session_write_close().
>
> Why?

A good reason would be several concurrent requests (which also might be
stylesheets, javascript, images, the lot), a website in which there are
'heavy' pages (take a long time to load), and users are likely to have
several windows open.

It is not strictly necessary to use session_write_close(), but a lot of
loading problems in a PHP-heavy site can be avoided with it. And if you're
done with a session, why not? session-closing/database-closing/unsetting
variables are just the kind of thing that might improve performance when
the server is stretched.

F'upped to c.l.php
--
Rik Wasmus

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 18:10:24 +0200, Scott Bryce
wrote:
>> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which
>> page to serve.
>
> Why?

Standard practice: single 'point-of-entry' website, serving up pages as
requested in the url. Saves a whole lot of code duplication, allthough it
might decrease performance. Look at it like an index file in the root
examing GET variables and serving up different pages according to the
given values. Only, for more easily remembered urls for humans, and the
kind of urls search-engines like, the url contains a pseudo-path: the
actual path does not exists, but is handled by a script which might be
anywhere.

> If you have stored the URL of the page you want to go to in a cookie,
> you should be looking for which page to serve in that cookie.

Never store that kind of a thing in a cookie. Use a session and just a
session cookie, store data in the server-side session.

> Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
> store in the cookie? Again, why? If I have a PHP script at
> example.com/user/login, why doesn't that script know its own URL?

Because the script might not be there? It's just a script, where the
request finally ends up being processed can have very little to do with
the requested URL.

> I may be way off base here, but your approach seems odd to me.

More a difference in approach, but a very normal one.
--
Rik Wasmus

Re: sessions and redirecting in opera

I ran into a login-related problem with NN4 about 6 years ago. This
was with an ASP site. The problem might be similar enough to suggest
somethig helpful:

I used a frameset that consisted of two frames. Everything was from
the same domain. On frame offered help links (that didn't require a
login). The other frame offered a login screen. Upon a successful
login, the login page was replaced by the applicaiton home page (in
the same frame). We were using the standard ASP Session to keep track
of the login.

This worked very well in IE and NN *** until *** we added SSL to
protect the login page. To do this, the login page url changed from
http://www.whatever.com/login.asp to https://www.whatever.com:443/login.asp.
The rest of the site url's remained the same. That broke the login
with NN4. It still worked fine with IE.

In NN4, the browser cookie was apparantly not getting set to record
the session id and thus the login state was lost. I experimented, but
was not able to come up with a simple solution. We ended up replacing
the frameset with a simple login page (no frameset). This allowed the
login to work in NN4 (cookie saved, even with SSL). Once logged in,
the user was redirected to the actual application, which then loaded
the frameset and two frames (help and application).

It looked like the problem was caused by bad vibes between NN4,
frames, SSL and cookies. I never found a smoking gun. I just changed
the design, which was not great to begin with.

BTW, I stopped using framesets almost 5 years ago. I stopped
supporting NN4 about 4 years ago. Haleluja!

I hope this helps.

Gerard Vignes

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 18:47:24 +0200, www.gerardvignes.com
wrote:

> I ran into a login-related problem with NN4 about 6 years ago. This
> was with an ASP site. The problem might be similar enough to suggest
> somethig helpful:
>
> I used a frameset that consisted of two frames. Everything was from
> the same domain. On frame offered help links (that didn't require a
> login). The other frame offered a login screen. Upon a successful
> login, the login page was replaced by the applicaiton home page (in
> the same frame). We were using the standard ASP Session to keep track
> of the login.
>
> This worked very well in IE and NN *** until *** we added SSL to
> protect the login page. To do this, the login page url changed from
> http://www.whatever.com/login.asp to
> https://www.whatever.com:443/login.asp.
> The rest of the site url's remained the same. That broke the login
> with NN4. It still worked fine with IE.
>
> In NN4, the browser cookie was apparantly not getting set to record
> the session id and thus the login state was lost. I experimented, but
> was not able to come up with a simple solution. We ended up replacing
> the frameset with a simple login page (no frameset). This allowed the
> login to work in NN4 (cookie saved, even with SSL). Once logged in,
> the user was redirected to the actual application, which then loaded
> the frameset and two frames (help and application).
>
> It looked like the problem was caused by bad vibes between NN4,
> frames, SSL and cookies. I never found a smoking gun.

The domain http://example.com is not necessarily https://example.com. A
cookie might be set for both or just one.

For PHP -> check wether session.cookie_secure is set (will only be sent
over https) or off (will be sent to both). See also
, for more detailed
explanation about cookies & their parameters.

--
Rik Wasmus

Re: sessions and redirecting in opera

"Rik" schreef in bericht
news:op.twuq52o5qnv3q9@metallium...
> On Fri, 10 Aug 2007 18:31:55 +0200, axlq wrote:
>
>> In article <46bc8925$0$25485$9a622dc7@news.kpnplanet.nl>,
>> amygdala wrote:
>>>
>>> "amygdala" schreef in bericht
>>> news:46bc8754$0$25476$9a622dc7@news.kpnplanet.nl...
>>>> Hello all,
>>>
>>>
>>>
>>> PS.: I forgot to mention that, before redirecting, I *do* let PHP
>>> perform a
>>> session_write_close().
>>
>> Why?
>
> A good reason would be several concurrent requests (which also might be
> stylesheets, javascript, images, the lot), a website in which there are
> 'heavy' pages (take a long time to load), and users are likely to have
> several windows open.
>
> It is not strictly necessary to use session_write_close(), but a lot of
> loading problems in a PHP-heavy site can be avoided with it. And if you're
> done with a session, why not? session-closing/database-closing/unsetting
> variables are just the kind of thing that might improve performance when
> the server is stretched.
>
> F'upped to c.l.php
> --
> Rik Wasmus

Exactly. To top it off, I implemented this because I assumed that by not
doing so, Opera's session might not be commited before the redirect.

Re: sessions and redirecting in opera

"Rik" schreef in bericht
news:op.twuritleqnv3q9@metallium...
> On Fri, 10 Aug 2007 18:10:24 +0200, Scott Bryce
> wrote:
>>> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which
>>> page to serve.
>>
>> Why?
>
> Standard practice: single 'point-of-entry' website, serving up pages as
> requested in the url. Saves a whole lot of code duplication, allthough it
> might decrease performance. Look at it like an index file in the root
> examing GET variables and serving up different pages according to the
> given values. Only, for more easily remembered urls for humans, and the
> kind of urls search-engines like, the url contains a pseudo-path: the
> actual path does not exists, but is handled by a script which might be
> anywhere.
>
>> If you have stored the URL of the page you want to go to in a cookie,
>> you should be looking for which page to serve in that cookie.
>
> Never store that kind of a thing in a cookie. Use a session and just a
> session cookie, store data in the server-side session.
>
>> Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
>> store in the cookie? Again, why? If I have a PHP script at
>> example.com/user/login, why doesn't that script know its own URL?
>
> Because the script might not be there? It's just a script, where the
> request finally ends up being processed can have very little to do with
> the requested URL.
>
>> I may be way off base here, but your approach seems odd to me.
>
> More a difference in approach, but a very normal one.
> --
> Rik Wasmus

Thanks for answering that one Rik, I couldn't have said it better. :-)

Re: sessions and redirecting in opera

"www.gerardvignes.com" schreef in bericht
news:1186764444.819081.108150@i13g2000prf.googlegroups.com.. .
>I ran into a login-related problem with NN4 about 6 years ago. This
> was with an ASP site. The problem might be similar enough to suggest
> somethig helpful:
>
> I used a frameset that consisted of two frames. Everything was from
> the same domain. On frame offered help links (that didn't require a
> login). The other frame offered a login screen. Upon a successful
> login, the login page was replaced by the applicaiton home page (in
> the same frame). We were using the standard ASP Session to keep track
> of the login.
>
> This worked very well in IE and NN *** until *** we added SSL to
> protect the login page. To do this, the login page url changed from
> http://www.whatever.com/login.asp to
> https://www.whatever.com:443/login.asp.
> The rest of the site url's remained the same. That broke the login
> with NN4. It still worked fine with IE.
>
> In NN4, the browser cookie was apparantly not getting set to record
> the session id and thus the login state was lost. I experimented, but
> was not able to come up with a simple solution. We ended up replacing
> the frameset with a simple login page (no frameset). This allowed the
> login to work in NN4 (cookie saved, even with SSL). Once logged in,
> the user was redirected to the actual application, which then loaded
> the frameset and two frames (help and application).
>
> It looked like the problem was caused by bad vibes between NN4,
> frames, SSL and cookies. I never found a smoking gun. I just changed
> the design, which was not great to begin with.
>
> BTW, I stopped using framesets almost 5 years ago. I stopped
> supporting NN4 about 4 years ago. Haleluja!
>
> I hope this helps.
>
> Gerard Vignes
>

Re: sessions and redirecting in opera

"www.gerardvignes.com" schreef in bericht
news:1186764444.819081.108150@i13g2000prf.googlegroups.com.. .
>I ran into a login-related problem with NN4 about 6 years ago. This
> was with an ASP site. The problem might be similar enough to suggest
> somethig helpful:
>
> I used a frameset that consisted of two frames. Everything was from
> the same domain. On frame offered help links (that didn't require a
> login). The other frame offered a login screen. Upon a successful
> login, the login page was replaced by the applicaiton home page (in
> the same frame). We were using the standard ASP Session to keep track
> of the login.

I don't use frames. Like you point out later on: haleluja!! ;-)

> This worked very well in IE and NN *** until *** we added SSL to
> protect the login page. To do this, the login page url changed from
> http://www.whatever.com/login.asp to
> https://www.whatever.com:443/login.asp.
> The rest of the site url's remained the same. That broke the login
> with NN4. It still worked fine with IE.

I don't use SSL either. But thanks for your input anyway.

Re: sessions and redirecting in opera

"Rik" schreef in bericht
news:op.twup20qfqnv3q9@metallium...
On Fri, 10 Aug 2007 17:39:55 +0200, amygdala wrote:

> Hello all,
>
> I have posted a similar question in comp.lang.php in the past, but
> haven't
> had any response to it then. I kinda swept the problem under the rug
> since
> then. But I would really like to resolve this issue once and for all now.
>
> The problem might be PHP related but since I only develop applications
> using
> PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
> crosspost to comp.lang.php and alt.www.webmaster. I assume the majority
> of
> frequent contributors of these groups have dealt with developing session
> management also, so I'm kind of hoping your experience in this field
> might
> resolve this issue.
>
> The problem is the following:
>
> User profiles on the site I'm developing will be publically available
> through:
>
> http://www.example.com/profile/view/
>
> A users own profile (when logged in) will be available through:
>
> http://www.example.com/profile/view/ or
> http://www.example.com/profile/ (which will redirect to last url)
>
> So when an anonymous user visits one of these last two pages, the
> requested
> page is stored as a referer in a session and the user is redirected to
>
> http://www.example.com/user/login/
>
> where the user is prompted to login.
>
> On succes it gets redirected to the stored referer url again. A pretty
> common procedure I would assume.
>
> This works fine on either IE or Firefox (windows). But in Opera I get
> multiple sessions created in the database of which one *does* contains a
> userId but Opera redirects back to the login page again.
>
> Only when I manually enter the target url I do get to see the logged in
> users profile page.
>
> My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page
> to
> serve. So, after much testing, I thought it might have something to do
> with
> Opera's favicon requests.

Hmm, FF & MSIE equally request that damn thing, shouldn't matter I think...

> I understand that this might be difficult to interpret without seeing any
> code. But since the code is pretty extensive, and I haven't really
> narrowed
> it down to a particular few lines, I thought I describe the problem
> without
> code first. Maybe somebody has had similar experiences and knows what the
> problem could be.

It's very hard to say. Are you sure you're not actually using the HTTP
REFERER header instead of the one stored in a session? It's pretty
unreliable, and very easy to disabled in Opera, i.e. the server never gets
this header. (Don't know wether it's a standard settings, it's a setting I
use nonetheless, and stored under'quick preferences', so easily accessable
for normal users). Another easily accessed Opera feature is to disable
redirecting. If you're relying on it to transfer the user to another page,
but don't exit your script after the redirect, chances are that in Opera
it might come across as 'the same page again'. So on a redirect, always do
something like:

$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click href="'.$target.'">here if it doesn't work';
exit; //<-----IMPORTANT!

A very easy mistake to make is also differnce in domain (for instance with
or without 'www.' in front of it, cookies that are sent vie https aren't
set by http and vice versa).

If that doesn't work, I'd set up a testpage instead of the normal redirect
to /user/login/, and instead of redirecting, dump the session-id & the
$_SESSION array, and exit. That might give you some insight in what
happens.

It could be a path issue for the cookie also though (as /profile &
/user/login are different, maybe the cookie is set carelessly, and there
are 2 different cookies for the differents paths)... If you use
LiveHTTPHeaders in FF or Fiddler in MSIE, what do you see as Set-Cookie
statements?

If all fails, I'd appreciate a live example, as I'm quite an Opera-fan,
and I can't let this slide :P

f'upped to comp.lang.php BTW.
--
Rik Wasmus

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 19:14:44 +0200, amygdala wrote:
>

Yes, that's what I said.... Or am I missing something?
--
Rik Wasmus

Re: sessions and redirecting in opera

First off: sorry about the empty posts people. I pushed accidentally pushed
the send button (twice :-S ).

"amygdala" schreef in bericht
news:46bc9d79$0$25487$9a622dc7@news.kpnplanet.nl...
>



> $target = 'http://www.example.com';
> header("Location: $target");
> echo 'You're be redirected to '.$target.'. Click > href="'.$target.'">here if it doesn't work';
> exit; //<-----IMPORTANT!
>

Well whatta you know!! As soon as I put this suggestion of yours after the
header("Location: $target"); it works! And mind you, not necessarily the
exit() part, but the echo part!! How strange is that? I'm loosing all sense
of logic on this one.

Could it be that Opera needs some kind of body content after a redirection
header? Or could it perhaps be that Opera indeed thinks that it should
redirect back to the login page again, since it is redirected to a page,
that redirected to the login page in the first place. lol

In other words, does Opera cache the redirect? In that it has been there
before and remembers: I need to go to the login page, cause nothing has
seemed to change?

Eerrr, that was kind of what you said already wasn't it?

I'm gonna investigate this a little more, cause this doesn't make enough
sense to me yet.

But low and behold, I got it working. Thanks a bunch so far Rik! That made
my day!

Re: sessions and redirecting in opera

"Rik" schreef in bericht
news:op.twuuoj2lqnv3q9@metallium...
> On Fri, 10 Aug 2007 19:14:44 +0200, amygdala wrote:
>>
>
> Yes, that's what I said.... Or am I missing something?
> --
> Rik Wasmus

LOL, sorry Rik, I'm a bit tense today, and therefor I accidentily pushed the
send button. No plagiarism intended. :)

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 20:07:03 +0200, amygdala wrote=
:

> First off: sorry about the empty posts people. I pushed accidentally =

> pushed
> the send button (twice :-S ).
>
> "amygdala" schreef in bericht
> news:46bc9d79$0$25487$9a622dc7@news.kpnplanet.nl...
>>
>
>
>
>> $target =3D 'http://www.example.com';
>> header("Location: $target");
>> echo 'You're be redirected to '.$target.'. Click >> href=3D"'.$target.'">here if it doesn't work';
>> exit; //<-----IMPORTANT!
>>
>
> Well whatta you know!! As soon as I put this suggestion of yours after=
=

> the
> header("Location: $target"); it works! And mind you, not necessarily t=
he
> exit() part, but the echo part!! How strange is that? I'm loosing all =
=

> sense
> of logic on this one.
>
> Could it be that Opera needs some kind of body content after a =

> redirection
> header? Or could it perhaps be that Opera indeed thinks that it should=

> redirect back to the login page again, since it is redirected to a pag=
e,
> that redirected to the login page in the first place. lol

Possiblity 1:
Opera -> Tools -> preferences -> Advanced -> Network -> Enable Automatic=
=

Redirection.

It's enabled by default, but can be disabled for whatever purpose. All t=
he =

more reason why a header redirect should be accompanied by some =

information one is redirected, and a script should die()/exit() after th=
at.

Possibility 2:
Opera get's the redirect, but still has the page with the same URL in =

cache, so decides to use that one. Set some header and/or html informati=
on =

these pages should not be cached.

Possibility 3:
The script isn't terminated after the first header-redirect, continues t=
o =

run, and effectively changes the redirect by a second header() call. =

Putting an echo directly after it will force the headers to be sent, so =
=

they cannot be replaced anymore, resulting in the first one being the on=
ly =

one, and thus the one obeyed by the browser. Another example why one =

should die()/exit() after a redirect.

//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
?>

//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
?>
-- =

Rik Wasmus

Re: sessions and redirecting in opera

..oO(amygdala)

>Exactly. To top it off, I implemented this because I assumed that by not
>doing so, Opera's session might not be commited before the redirect.

Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.

Micha

Re: sessions and redirecting in opera

"Michael Fesser" schreef in bericht
news:albpb3dnnonfa1bv9g0c82b1mn557ml8ab@4ax.com...
> .oO(amygdala)
>
>>Exactly. To top it off, I implemented this because I assumed that by not
>>doing so, Opera's session might not be commited before the redirect.
>
> Are you sure you really understood how sessions work? The browser's
> only task is to keep the session ID, that's it. The handling of the
> session itself - open, read, write, close - is done on the server.
> Sessions are browser-independent, there's nothing to commit.
>
> Micha

Actually I do understand how sessions work, that's why this whole thing
didn't make any sense to me. Why would it work on other browsers, but not on
Opera.

But when all logic fails, I tend to resort to ad-hoc trial and error,
including these kind of things. But Rik's latest post in which he poses some
possibilities, start to make sense. I'm gonna keep the exit() statement
behind the redirects, but I'm still gonna investigate whether my application
indeed is doing something else after the redirect, that it shouldn't.

Re: sessions and redirecting in opera

On Fri, 10 Aug 2007 20:32:45 +0200, Michael Fesser wrote:

> .oO(amygdala)
>
>> Exactly. To top it off, I implemented this because I assumed that by not
>> doing so, Opera's session might not be commited before the redirect.
>
> Are you sure you really understood how sessions work? The browser's
> only task is to keep the session ID, that's it. The handling of the
> session itself - open, read, write, close - is done on the server.
> Sessions are browser-independent, there's nothing to commit.

Are you sure you understood how redirecting and sessions works? A script
that has sent a header redirect _can_ continue on and one, doing heavy
work that lasts for an x amount of time. The session will only be closed
automatically when the script ends. If the user is allready requesting the
following page it might slow him down considerably, as the session data
isn't made available untill the end of that renegade script...

So, if a session is no longer needed, it's a wise idea to close is, just
not very necessary in your normal garden variety of PHP scripts.

--
Rik Wasmus

Re: sessions and redirecting in opera

"Rik" schreef in bericht
news:op.twuwcnszqnv3q9@metallium...
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala wrote:

> First off: sorry about the empty posts people. I pushed accidentally
> pushed
> the send button (twice :-S ).
>
> "amygdala" schreef in bericht
> news:46bc9d79$0$25487$9a622dc7@news.kpnplanet.nl...
>>
>
>
>
>> $target = 'http://www.example.com';
>> header("Location: $target");
>> echo 'You're be redirected to '.$target.'. Click >> href="'.$target.'">here if it doesn't work';
>> exit; //<-----IMPORTANT!
>>
>
> Well whatta you know!! As soon as I put this suggestion of yours after
> the
> header("Location: $target"); it works! And mind you, not necessarily the
> exit() part, but the echo part!! How strange is that? I'm loosing all
> sense
> of logic on this one.
>
> Could it be that Opera needs some kind of body content after a
> redirection
> header? Or could it perhaps be that Opera indeed thinks that it should
> redirect back to the login page again, since it is redirected to a page,
> that redirected to the login page in the first place. lol

Somehow, your posts don't get quoted properly by my newsreader (yes, its OE
:-S ), so I'll resort to my own:


Possiblity 1:
Opera -> Tools -> preferences -> Advanced -> Network -> Enable Automatic
Redirection.

It's enabled by default, but can be disabled for whatever purpose. All the
more reason why a header redirect should be accompanied by some
information one is redirected, and a script should die()/exit() after that.


I know, but it's not an issue.


Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html information
these pages should not be cached.


Yes, that's a reasonable assumption, I will look into that a little more.


Possibility 3:
The script isn't terminated after the first header-redirect, continues to
run, and effectively changes the redirect by a second header() call.
Putting an echo directly after it will force the headers to be sent, so
they cannot be replaced anymore, resulting in the first one being the only
one, and thus the one obeyed by the browser. Another example why one
should die()/exit() after a redirect.

//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
?>

//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
?>


Yes, that makes sense. Although my application should not behave this way,
since it only calls for one function in one controller class per page, I
will look into this a little more. I could very well be overlooking flaws in
my application logics.

Thanks for the great suggestions Rik. You've been very helpful.

Cheers!

Re: sessions and redirecting in opera

amygdala wrote:
> Somehow, your posts don't get quoted properly by my newsreader (yes,
> its OE :-S ), so I'll resort to my own:

OE Quotefix, a must-have for MSOE users :)

Re: sessions and redirecting in opera

..oO(Rik)

>On Fri, 10 Aug 2007 20:32:45 +0200, Michael Fesser wrote:
>
>> Are you sure you really understood how sessions work? The browser's
>> only task is to keep the session ID, that's it. The handling of the
>> session itself - open, read, write, close - is done on the server.
>> Sessions are browser-independent, there's nothing to commit.
>
>Are you sure you understood how redirecting and sessions works?

Yes.

>[...]
>
>So, if a session is no longer needed, it's a wise idea to close is, just
>not very necessary in your normal garden variety of PHP scripts.

That's all correct - I was just picking on the "Opera's session might
not be commited before the redirect". Maybe it was just written in a
misleading way, but some problems simply cannot be related to a
particular browser.

And since I'm an Opera fan as well (since v3.60) ... ;-)

Micha

Re: sessions and redirecting in opera

Rik wrote:
> amygdala wrote:
>> Somehow, your posts don't get quoted properly by my newsreader (yes,
>> its OE :-S ), so I'll resort to my own:
>
> OE Quotefix, a must-have for MSOE users :)

Thanks for the tip Rik! Installed it. Seems to work like a charm.

Re: sessions and redirecting in opera

Rik wrote:
> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
> wrote:
>>
>> Could it be that Opera needs some kind of body content after a
>> redirection
>> header? Or could it perhaps be that Opera indeed thinks that it
>> should redirect back to the login page again, since it is redirected
>> to a page, that redirected to the login page in the first place. lol
>
> Possiblity 1:
> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
> Automatic Redirection.
>
> It's enabled by default, but can be disabled for whatever purpose.
> All the more reason why a header redirect should be accompanied by
> some information one is redirected, and a script should die()/exit()
> after that.
> Possibility 2:
> Opera get's the redirect, but still has the page with the same URL in
> cache, so decides to use that one. Set some header and/or html
> information these pages should not be cached.
>
> Possibility 3:
> The script isn't terminated after the first header-redirect,
> continues to run, and effectively changes the redirect by a second
> header() call. Putting an echo directly after it will force the
> headers to be sent, so they cannot be replaced anymore, resulting in
> the first one being the only one, and thus the one obeyed by the
> browser. Another example why one should die()/exit() after a redirect.
>
> > //this will offcourse end in /second.html
> header('Location: /first.html');
> header('Location: /second.html');
>>
>
> > //this will end in /first.html
> header('Location: /first.html');
> flush();
> header('Location: /second.html');

This thing still has me puzzled. What I did is the following:

My SessionHandler class has the following method:

public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click if it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}

Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem persists
if I leave out the echo part you see above between the comments.

So, from my experience it seems as if Opera wants some body content for the
redirect to work and revalidate the url I landed on before I had to log in.

Does anyone have any other clue as to what might be going on here?

Thanks.

Re: sessions and redirecting in opera

amygdala wrote:
> Rik wrote:
>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>> wrote:
>>> Could it be that Opera needs some kind of body content after a
>>> redirection
>>> header? Or could it perhaps be that Opera indeed thinks that it
>>> should redirect back to the login page again, since it is redirected
>>> to a page, that redirected to the login page in the first place. lol
>> Possiblity 1:
>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>> Automatic Redirection.
>>
>> It's enabled by default, but can be disabled for whatever purpose.
>> All the more reason why a header redirect should be accompanied by
>> some information one is redirected, and a script should die()/exit()
>> after that.
>> Possibility 2:
>> Opera get's the redirect, but still has the page with the same URL in
>> cache, so decides to use that one. Set some header and/or html
>> information these pages should not be cached.
>>
>> Possibility 3:
>> The script isn't terminated after the first header-redirect,
>> continues to run, and effectively changes the redirect by a second
>> header() call. Putting an echo directly after it will force the
>> headers to be sent, so they cannot be replaced anymore, resulting in
>> the first one being the only one, and thus the one obeyed by the
>> browser. Another example why one should die()/exit() after a redirect.
>>
>> >> //this will offcourse end in /second.html
>> header('Location: /first.html');
>> header('Location: /second.html');
>> >> //this will end in /first.html
>> header('Location: /first.html');
>> flush();
>> header('Location: /second.html');
>
> This thing still has me puzzled. What I did is the following:
>
> My SessionHandler class has the following method:
>
> public function redirect( $url )
> {
> session_write_close();
> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
> header( 'Cache-Control: post-check=0, pre-check=0', false );
> header( 'Pragma: no-cache' );
> header( 'HTTP/1.0 302 Moved Temporarily' );
> header( 'Location: ' . $url );
> // this part between the comments is important
> echo 'You\'re being redirected to ' . $url . ' .
> Click if it doesn\'t work';
> // end important part
> exit(); // exit doesn't really make a difference for Opera
> }
>
> Since I have now included the exit() statement I am sure that this is the
> last thing done by the application when redirecting. Also, I have added
> cache control headers and the likes. But still in Opera the problem persists
> if I leave out the echo part you see above between the comments.
>
> So, from my experience it seems as if Opera wants some body content for the
> redirect to work and revalidate the url I landed on before I had to log in.
>
> Does anyone have any other clue as to what might be going on here?
>
> Thanks.
>
>

Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.

If you have your header set up appropriately, they will be redirected.
All the message might do is screw things up for the browser.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: sessions and redirecting in opera

"Jerry Stuckle" schreef in bericht
news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
> amygdala wrote:
>>
>> This thing still has me puzzled. What I did is the following:
>>
>> My SessionHandler class has the following method:
>>
>> public function redirect( $url )
>> {
>> session_write_close();
>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>> header( 'Cache-Control: post-check=0, pre-check=0', false );
>> header( 'Pragma: no-cache' );
>> header( 'HTTP/1.0 302 Moved Temporarily' );
>> header( 'Location: ' . $url );
>> // this part between the comments is important
>> echo 'You\'re being redirected to ' . $url . ' .
>> Click if it doesn\'t work';
>> // end important part
>> exit(); // exit doesn't really make a difference for Opera
>> }
>>
>> Since I have now included the exit() statement I am sure that this is the
>> last thing done by the application when redirecting. Also, I have added
>> cache control headers and the likes. But still in Opera the problem
>> persists if I leave out the echo part you see above between the comments.
>>
>> So, from my experience it seems as if Opera wants some body content for
>> the redirect to work and revalidate the url I landed on before I had to
>> log in.
>>
>> Does anyone have any other clue as to what might be going on here?
>>
>> Thanks.
>
> Why are you sending a message they will never see, anyway? Normally a
> redirect header has NO text associated with it.
>
> If you have your header set up appropriately, they will be redirected. All
> the message might do is screw things up for the browser.

Because as Rik has pointed out earlier: some browsers might not obey the
request for a redirect. I predominantly browse using Opera, and in Opera,
you can also *choose* not to be redirected automatically. So having said
that, it makes sense to add an extra option for visitors, when they are not
redirected automatically.

Re: sessions and redirecting in opera

"Jerry Stuckle" schreef in bericht
news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
> amygdala wrote:
>> Rik wrote:
>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>> wrote:
>>>> Could it be that Opera needs some kind of body content after a
>>>> redirection
>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>> should redirect back to the login page again, since it is redirected
>>>> to a page, that redirected to the login page in the first place. lol
>>> Possiblity 1:
>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>> Automatic Redirection.
>>>
>>> It's enabled by default, but can be disabled for whatever purpose.
>>> All the more reason why a header redirect should be accompanied by
>>> some information one is redirected, and a script should die()/exit()
>>> after that.
>>> Possibility 2:
>>> Opera get's the redirect, but still has the page with the same URL in
>>> cache, so decides to use that one. Set some header and/or html
>>> information these pages should not be cached.
>>>
>>> Possibility 3:
>>> The script isn't terminated after the first header-redirect,
>>> continues to run, and effectively changes the redirect by a second
>>> header() call. Putting an echo directly after it will force the
>>> headers to be sent, so they cannot be replaced anymore, resulting in
>>> the first one being the only one, and thus the one obeyed by the
>>> browser. Another example why one should die()/exit() after a redirect.
>>>
>>> >>> //this will offcourse end in /second.html
>>> header('Location: /first.html');
>>> header('Location: /second.html');
>>> >>> //this will end in /first.html
>>> header('Location: /first.html');
>>> flush();
>>> header('Location: /second.html');
>>
>> This thing still has me puzzled. What I did is the following:
>>
>> My SessionHandler class has the following method:
>>
>> public function redirect( $url )
>> {
>> session_write_close();
>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>> header( 'Cache-Control: post-check=0, pre-check=0', false );
>> header( 'Pragma: no-cache' );
>> header( 'HTTP/1.0 302 Moved Temporarily' );
>> header( 'Location: ' . $url );
>> // this part between the comments is important
>> echo 'You\'re being redirected to ' . $url . ' .
>> Click if it doesn\'t work';
>> // end important part
>> exit(); // exit doesn't really make a difference for Opera
>> }
>>
>> Since I have now included the exit() statement I am sure that this is the
>> last thing done by the application when redirecting. Also, I have added
>> cache control headers and the likes. But still in Opera the problem
>> persists if I leave out the echo part you see above between the comments.
>>
>> So, from my experience it seems as if Opera wants some body content for
>> the redirect to work and revalidate the url I landed on before I had to
>> log in.
>>
>> Does anyone have any other clue as to what might be going on here?
>>
>> Thanks.
>
> Why are you sending a message they will never see, anyway? Normally a
> redirect header has NO text associated with it.
>
> If you have your header set up appropriately, they will be redirected. All
> the message might do is screw things up for the browser.
>

PS.: Correct me if I'm wrong, but are my headers not set up properly?

Re: sessions and redirecting in opera

amygdala wrote:
> "Jerry Stuckle" schreef in bericht
> news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
>> amygdala wrote:
>>> Rik wrote:
>>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>>> wrote:
>>>>> Could it be that Opera needs some kind of body content after a
>>>>> redirection
>>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>>> should redirect back to the login page again, since it is redirected
>>>>> to a page, that redirected to the login page in the first place. lol
>>>> Possiblity 1:
>>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>>> Automatic Redirection.
>>>>
>>>> It's enabled by default, but can be disabled for whatever purpose.
>>>> All the more reason why a header redirect should be accompanied by
>>>> some information one is redirected, and a script should die()/exit()
>>>> after that.
>>>> Possibility 2:
>>>> Opera get's the redirect, but still has the page with the same URL in
>>>> cache, so decides to use that one. Set some header and/or html
>>>> information these pages should not be cached.
>>>>
>>>> Possibility 3:
>>>> The script isn't terminated after the first header-redirect,
>>>> continues to run, and effectively changes the redirect by a second
>>>> header() call. Putting an echo directly after it will force the
>>>> headers to be sent, so they cannot be replaced anymore, resulting in
>>>> the first one being the only one, and thus the one obeyed by the
>>>> browser. Another example why one should die()/exit() after a redirect.
>>>>
>>>> >>>> //this will offcourse end in /second.html
>>>> header('Location: /first.html');
>>>> header('Location: /second.html');
>>>> >>>> //this will end in /first.html
>>>> header('Location: /first.html');
>>>> flush();
>>>> header('Location: /second.html');
>>> This thing still has me puzzled. What I did is the following:
>>>
>>> My SessionHandler class has the following method:
>>>
>>> public function redirect( $url )
>>> {
>>> session_write_close();
>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
>>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>>> header( 'Cache-Control: post-check=0, pre-check=0', false );
>>> header( 'Pragma: no-cache' );
>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>> header( 'Location: ' . $url );
>>> // this part between the comments is important
>>> echo 'You\'re being redirected to ' . $url . ' .
>>> Click if it doesn\'t work';
>>> // end important part
>>> exit(); // exit doesn't really make a difference for Opera
>>> }
>>>
>>> Since I have now included the exit() statement I am sure that this is the
>>> last thing done by the application when redirecting. Also, I have added
>>> cache control headers and the likes. But still in Opera the problem
>>> persists if I leave out the echo part you see above between the comments.
>>>
>>> So, from my experience it seems as if Opera wants some body content for
>>> the redirect to work and revalidate the url I landed on before I had to
>>> log in.
>>>
>>> Does anyone have any other clue as to what might be going on here?
>>>
>>> Thanks.
>> Why are you sending a message they will never see, anyway? Normally a
>> redirect header has NO text associated with it.
>>
>> If you have your header set up appropriately, they will be redirected. All
>> the message might do is screw things up for the browser.
>>
>
> PS.: Correct me if I'm wrong, but are my headers not set up properly?
>
>

Well, I don't see why you have the session_write_close() - the session
will be closed during exit() processing, anyway.

I also don't see why you have all of the cache control stuff. It's
completely unnecessary in this case.

Keep it simple - the 302 moved and location should be all you need.

And quite frankly, I wouldn't worry about opera users who disable the
redirects. After all - if you did the redirect in the normal way
(.htaccess or httpd.conf file), they wouldn't get a message. So they
must be used to getting blank screens.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: sessions and redirecting in opera

On Mon, 13 Aug 2007 00:24:18 +0200, amygdala wrote=
:

> Rik wrote:
>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>> wrote:
>>>
>>> Could it be that Opera needs some kind of body content after a
>>> redirection
>>> header? Or could it perhaps be that Opera indeed thinks that it
>>> should redirect back to the login page again, since it is redirected=

>>> to a page, that redirected to the login page in the first place. lol=

>>
>> Possiblity 1:
>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>> Automatic Redirection.
>>
>> It's enabled by default, but can be disabled for whatever purpose.
>> All the more reason why a header redirect should be accompanied by
>> some information one is redirected, and a script should die()/exit()
>> after that.
>> Possibility 2:
>> Opera get's the redirect, but still has the page with the same URL in=

>> cache, so decides to use that one. Set some header and/or html
>> information these pages should not be cached.
>>
>> Possibility 3:
>> The script isn't terminated after the first header-redirect,
>> continues to run, and effectively changes the redirect by a second
>> header() call. Putting an echo directly after it will force the
>> headers to be sent, so they cannot be replaced anymore, resulting in
>> the first one being the only one, and thus the one obeyed by the
>> browser. Another example why one should die()/exit() after a redirect=
..
>>
>> >> //this will offcourse end in /second.html
>> header('Location: /first.html');
>> header('Location: /second.html');
>>>
>>
>> >> //this will end in /first.html
>> header('Location: /first.html');
>> flush();
>> header('Location: /second.html');
>
> This thing still has me puzzled. What I did is the following:
>
> My SessionHandler class has the following method:
>
> public function redirect( $url )
> {
> session_write_close();
> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
> header( 'Cache-Control: post-check=3D0, pre-check=3D0', false );
> header( 'Pragma: no-cache' );
> header( 'HTTP/1.0 302 Moved Temporarily' );
> header( 'Location: ' . $url );
> // this part between the comments is important
> echo 'You\'re being redirected to ' . $url . ' .
> Click if it doesn\'t work';
> // end important part
> exit(); // exit doesn't really make a difference for Opera
> }
>
> Since I have now included the exit() statement I am sure that this is =
the
> last thing done by the application when redirecting. Also, I have adde=
d
> cache control headers and the likes. But still in Opera the problem =

> persists
> if I leave out the echo part you see above between the comments.
>
> So, from my experience it seems as if Opera wants some body content fo=
r =

> the
> redirect to work and revalidate the url I landed on before I had to lo=
g =

> in.

Can you set this up somewhere accessable? I'm curious what happens if I =
=

try it in Opera here. Never gave me problems before.
-- =

Rik Wasmus

Re: sessions and redirecting in opera

Rik wrote:
> On Mon, 13 Aug 2007 00:24:18 +0200, amygdala
> wrote:
>> Rik wrote:
>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>> wrote:
>>>>
>>>> Could it be that Opera needs some kind of body content after a
>>>> redirection
>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>> should redirect back to the login page again, since it is
>>>> redirected to a page, that redirected to the login page in the
>>>> first place. lol
>>>
>>> Possiblity 1:
>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>> Automatic Redirection.
>>>
>>> It's enabled by default, but can be disabled for whatever purpose.
>>> All the more reason why a header redirect should be accompanied by
>>> some information one is redirected, and a script should die()/exit()
>>> after that.
>>> Possibility 2:
>>> Opera get's the redirect, but still has the page with the same URL
>>> in cache, so decides to use that one. Set some header and/or html
>>> information these pages should not be cached.
>>>
>>> Possibility 3:
>>> The script isn't terminated after the first header-redirect,
>>> continues to run, and effectively changes the redirect by a second
>>> header() call. Putting an echo directly after it will force the
>>> headers to be sent, so they cannot be replaced anymore, resulting in
>>> the first one being the only one, and thus the one obeyed by the
>>> browser. Another example why one should die()/exit() after a
>>> redirect. >>> //this will offcourse end in /second.html
>>> header('Location: /first.html');
>>> header('Location: /second.html');
>>>>
>>>
>>> >>> //this will end in /first.html
>>> header('Location: /first.html');
>>> flush();
>>> header('Location: /second.html');
>>
>> This thing still has me puzzled. What I did is the following:
>>
>> My SessionHandler class has the following method:
>>
>> public function redirect( $url )
>> {
>> session_write_close();
>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>> header( 'Cache-Control: post-check=0, pre-check=0', false );
>> header( 'Pragma: no-cache' );
>> header( 'HTTP/1.0 302 Moved Temporarily' );
>> header( 'Location: ' . $url );
>> // this part between the comments is important
>> echo 'You\'re being redirected to ' . $url . ' .
>> Click if it doesn\'t work';
>> // end important part
>> exit(); // exit doesn't really make a difference for Opera
>> }
>>
>> Since I have now included the exit() statement I am sure that this
>> is the last thing done by the application when redirecting. Also, I
>> have added cache control headers and the likes. But still in Opera
>> the problem persists
>> if I leave out the echo part you see above between the comments.
>>
>> So, from my experience it seems as if Opera wants some body content
>> for the
>> redirect to work and revalidate the url I landed on before I had to
>> log in.
>
> Can you set this up somewhere accessable? I'm curious what happens if
> I try it in Opera here. Never gave me problems before.

Hi Rik,

I've set up little example (without the echo part in the redirect method)
which you should be able to access temporarily through:

http://amygdala.kicks-ass.net/profile/

(Please let me know if you are not able to access it.)

If all goes well, this will automatically redirect you to the login page.
From there on use:

username: demo
password: demodemo (yes, 8 chars)

In my Opera version (9.02) this brings up the login page again, instead of
redirecting me to

http://amygdala.kicks-ass.net/profile/view/demo

When I manually go to the above url after logging in, I do get to see a
var_dump as intended.

Bedankt alvast! (Thank you in advance)

Re: sessions and redirecting in opera

amygdala wrote:
> Rik wrote:
>> On Mon, 13 Aug 2007 00:24:18 +0200, amygdala
>>>
>>> My SessionHandler class has the following method:
>>>
>>> public function redirect( $url )
>>> {
>>> session_write_close();
>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
>>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>>> header( 'Cache-Control: post-check=0, pre-check=0', false );
>>> header( 'Pragma: no-cache' );
>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>> header( 'Location: ' . $url );
>>> // this part between the comments is important
>>> echo 'You\'re being redirected to ' . $url . ' .
>>> Click if it doesn\'t work';
>>> // end important part
>>> exit(); // exit doesn't really make a difference for Opera
>>> }
>>>
>>> Since I have now included the exit() statement I am sure that this
>>> is the last thing done by the application when redirecting. Also, I
>>> have added cache control headers and the likes. But still in Opera
>>> the problem persists
>>> if I leave out the echo part you see above between the comments.
>>>
>>> So, from my experience it seems as if Opera wants some body content
>>> for the
>>> redirect to work and revalidate the url I landed on before I had to
>>> log in.
>>
>> Can you set this up somewhere accessable? I'm curious what happens if
>> I try it in Opera here. Never gave me problems before.
>
> Hi Rik,
>
> I've set up little example (without the echo part in the redirect
> method) which you should be able to access temporarily through:
>
> http://amygdala.kicks-ass.net/profile/
>
> (Please let me know if you are not able to access it.)
>
> If all goes well, this will automatically redirect you to the login
> page. From there on use:
>
> username: demo
> password: demodemo (yes, 8 chars)
>
> In my Opera version (9.02) this brings up the login page again,
> instead of redirecting me to
>
> http://amygdala.kicks-ass.net/profile/view/demo
>
> When I manually go to the above url after logging in, I do get to see
> a var_dump as intended.
>
> Bedankt alvast! (Thank you in advance)

Alright, this is strange:

When I access my own example through a proxy (using the above url) it works
as intended. Come to think of it, I do recall reading somewhere that Opera
sometimes has problems with cookies when developing on a localhost server.

Are you aware of any such thing?

Re: sessions and redirecting in opera

Jerry Stuckle wrote:
> amygdala wrote:
>> "Jerry Stuckle" schreef in bericht
>> news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
>>> amygdala wrote:
>>>> Rik wrote:
>>>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>>>> wrote:
>>>>>> Could it be that Opera needs some kind of body content after a
>>>>>> redirection
>>>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>>>> should redirect back to the login page again, since it is
>>>>>> redirected to a page, that redirected to the login page in the
>>>>>> first place. lol
>>>>> Possiblity 1:
>>>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>>>> Automatic Redirection.
>>>>>
>>>>> It's enabled by default, but can be disabled for whatever purpose.
>>>>> All the more reason why a header redirect should be accompanied by
>>>>> some information one is redirected, and a script should
>>>>> die()/exit() after that.
>>>>> Possibility 2:
>>>>> Opera get's the redirect, but still has the page with the same
>>>>> URL in cache, so decides to use that one. Set some header and/or
>>>>> html information these pages should not be cached.
>>>>>
>>>>> Possibility 3:
>>>>> The script isn't terminated after the first header-redirect,
>>>>> continues to run, and effectively changes the redirect by a second
>>>>> header() call. Putting an echo directly after it will force the
>>>>> headers to be sent, so they cannot be replaced anymore, resulting
>>>>> in the first one being the only one, and thus the one obeyed by
>>>>> the browser. Another example why one should die()/exit() after a
>>>>> redirect. >>>>> //this will offcourse end in /second.html
>>>>> header('Location: /first.html');
>>>>> header('Location: /second.html');
>>>>> >>>>> //this will end in /first.html
>>>>> header('Location: /first.html');
>>>>> flush();
>>>>> header('Location: /second.html');
>>>> This thing still has me puzzled. What I did is the following:
>>>>
>>>> My SessionHandler class has the following method:
>>>>
>>>> public function redirect( $url )
>>>> {
>>>> session_write_close();
>>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
>>>> ); header( 'Cache-Control: no-store, no-cache, must-revalidate'
>>>> ); header( 'Cache-Control: post-check=0, pre-check=0', false );
>>>> header( 'Pragma: no-cache' );
>>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>>> header( 'Location: ' . $url );
>>>> // this part between the comments is important
>>>> echo 'You\'re being redirected to ' . $url . ' .
>>>> Click if it doesn\'t work';
>>>> // end important part
>>>> exit(); // exit doesn't really make a difference for Opera
>>>> }
>>>>
>>>> Since I have now included the exit() statement I am sure that this
>>>> is the last thing done by the application when redirecting. Also,
>>>> I have added cache control headers and the likes. But still in
>>>> Opera the problem persists if I leave out the echo part you see
>>>> above between the comments. So, from my experience it seems as if Opera
>>>> wants some body
>>>> content for the redirect to work and revalidate the url I landed
>>>> on before I had to log in.
>>>>
>>>> Does anyone have any other clue as to what might be going on here?
>>>>
>>>> Thanks.
>>> Why are you sending a message they will never see, anyway? Normally a
>>> redirect header has NO text associated with it.
>>>
>>> If you have your header set up appropriately, they will be
>>> redirected. All the message might do is screw things up for the
>>> browser.
>>
>> PS.: Correct me if I'm wrong, but are my headers not set up properly?
>>
>>
>
> Well, I don't see why you have the session_write_close() - the session
> will be closed during exit() processing, anyway.
>
> I also don't see why you have all of the cache control stuff. It's
> completely unnecessary in this case.
>
> Keep it simple - the 302 moved and location should be all you need.

I would think so to, but if you have read the entire thread you would see
that I am having trouble with getting it to work as expected in Opera. So I
thought I'ld use every option at my disposal to make sure the redirect and
the session saving works as expected.

But now, it looks like the Opera problem only exists when accessing the
application local on localhost. (See my reply to Rik)

Re: sessions and redirecting in opera

On Mon, 13 Aug 2007 11:53:58 +0200, amygdala wrote=
:
>>> This thing still has me puzzled. What I did is the following:
>>>
>>> My SessionHandler class has the following method:
>>>
>>> public function redirect( $url )
>>> {
>>> session_write_close();
>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );=

>>> header( 'Cache-Control: no-store, no-cache, must-revalidate' );
>>> header( 'Cache-Control: post-check=3D0, pre-check=3D0', false );
>>> header( 'Pragma: no-cache' );
>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>> header( 'Location: ' . $url );
>>> // this part between the comments is important
>>> echo 'You\'re being redirected to ' . $url . ' .
>>> Click if it doesn\'t work';
>>> // end important part
>>> exit(); // exit doesn't really make a difference for Opera
>>> }
>>>
>>> Since I have now included the exit() statement I am sure that this
>>> is the last thing done by the application when redirecting. Also, I
>>> have added cache control headers and the likes. But still in Opera
>>> the problem persists
>>> if I leave out the echo part you see above between the comments.
>>
>> Can you set this up somewhere accessable? I'm curious what happens if=

>> I try it in Opera here. Never gave me problems before.
>
> I've set up little example (without the echo part in the redirect meth=
od)
> which you should be able to access temporarily through:
>
> http://amygdala.kicks-ass.net/profile/
>
> (Please let me know if you are not able to access it.)

HTTP/1.x 302 Moved Temporarily
....
Set-Cookie: PHPSESSID=3Djhiktdcd4efk720iqahhhquokhm24ill; path=3D/
Set-Cookie: PHPSESSID=3Dupgdihd7gbiqnen492advkiu0c0piv4v; path=3D/
Location: http://127.0.0.1/user/login/
....

I haven't set up your site on my local box, so no, it's not working :).

> If all goes well, this will automatically redirect you to the login pa=
ge.

OK, on another domain perhaps, so that might get some freaky results in =
=

cookies/sessions. When I manually go to =

http://amygdala.kicks-ass.net/user/login/ I can see the form, and when =

logging in I'm again redirected to 127.0.0.1 (/profile/view/), which is =
=

offcourse not found. So, manually going to =

http://amygdala.kicks-ass.net/profile/view/, I get redirected without a =
=

hitch to http://amygdala.kicks-ass.net/profile/view/demo, and I see a =

var_dump of a User object, seems OK to me.

Redirecting seems fine here (Opera 9.23), only to the wrong domain... I =
=

offcourse continuously get the 'page not found' for the 127.0.0.1 =

redirects, but I am redirected nonetheless. What if you use the =

$_SERVER['HTTP_HOST'] in the url to which you redirect?

> Bedankt alvast! (Thank you in advance)

Geen probleem :-)
-- =

Rik Wasmus

Re: sessions and redirecting in opera

On Mon, 13 Aug 2007 12:04:54 +0200, amygdala wrote:
> Alright, this is strange:
>
> When I access my own example through a proxy (using the above url) it
> works
> as intended. Come to think of it, I do recall reading somewhere that
> Opera
> sometimes has problems with cookies when developing on a localhost
> server.
>
> Are you aware of any such thing?

Only domain conflicts if they aren't set properly :P
--
Rik Wasmus

Re: sessions and redirecting in opera

Rik wrote:
> On Mon, 13 Aug 2007 11:53:58 +0200, amygdala
> wrote:
>>>> This thing still has me puzzled. What I did is the following:
>>>>
>>>> My SessionHandler class has the following method:
>>>>
>>>> public function redirect( $url )
>>>> {
>>>> session_write_close();
>>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
>>>> ); header( 'Cache-Control: no-store, no-cache, must-revalidate'
>>>> ); header( 'Cache-Control: post-check=0, pre-check=0', false );
>>>> header( 'Pragma: no-cache' );
>>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>>> header( 'Location: ' . $url );
>>>> // this part between the comments is important
>>>> echo 'You\'re being redirected to ' . $url . ' .
>>>> Click if it doesn\'t work';
>>>> // end important part
>>>> exit(); // exit doesn't really make a difference for Opera
>>>> }
>>>>
>>>> Since I have now included the exit() statement I am sure that this
>>>> is the last thing done by the application when redirecting. Also, I
>>>> have added cache control headers and the likes. But still in Opera
>>>> the problem persists
>>>> if I leave out the echo part you see above between the comments.
>>>
>>> Can you set this up somewhere accessable? I'm curious what happens
>>> if I try it in Opera here. Never gave me problems before.
>>
>> I've set up little example (without the echo part in the redirect
>> method) which you should be able to access temporarily through:
>>
>> http://amygdala.kicks-ass.net/profile/
>>
>> (Please let me know if you are not able to access it.)
>
> HTTP/1.x 302 Moved Temporarily
> ...
> Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
> Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
> Location: http://127.0.0.1/user/login/
> ...
>
> I haven't set up your site on my local box, so no, it's not working
> :).

Errrr, sorry about that Rik, forgot to change

define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );

to

define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );

>> If all goes well, this will automatically redirect you to the login
>> page.
>
> OK, on another domain perhaps, so that might get some freaky results
> in cookies/sessions. When I manually go to
> http://amygdala.kicks-ass.net/user/login/ I can see the form, and when
> logging in I'm again redirected to 127.0.0.1 (/profile/view/), which
> is offcourse not found. So, manually going to
> http://amygdala.kicks-ass.net/profile/view/, I get redirected without
> a hitch to http://amygdala.kicks-ass.net/profile/view/demo, and I see
> a var_dump of a User object, seems OK to me.

But then this should be OK indeed.

> Redirecting seems fine here (Opera 9.23), only to the wrong domain...
> I offcourse continuously get the 'page not found' for the 127.0.0.1
> redirects, but I am redirected nonetheless. What if you use the
> $_SERVER['HTTP_HOST'] in the url to which you redirect?
>
>> Bedankt alvast! (Thank you in advance)
>
> Geen probleem :-)

Thanks again!

Re: sessions and redirecting in opera

On Mon, 13 Aug 2007 12:33:20 +0200, amygdala wrote=
:
> Rik wrote:
>>> I've set up little example (without the echo part in the redirect
>>> method) which you should be able to access temporarily through:
>>>
>>> http://amygdala.kicks-ass.net/profile/
>>>
>>> (Please let me know if you are not able to access it.)
>>
>> HTTP/1.x 302 Moved Temporarily
>> ...
>> Set-Cookie: PHPSESSID=3Djhiktdcd4efk720iqahhhquokhm24ill; path=3D/
>> Set-Cookie: PHPSESSID=3Dupgdihd7gbiqnen492advkiu0c0piv4v; path=3D/
>> Location: http://127.0.0.1/user/login/
>> ...
>>
>> I haven't set up your site on my local box, so no, it's not working
>> :).
>
> Errrr, sorry about that Rik, forgot to change
>
> define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );
>
> to
>
> define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );

Ah, and everything works like a charm :P (allthough the double set-cooki=
e =

PHPSESSID should be taken care of).

So, possibly a server/domain issue somewhere when developing locally, =

works OK on the net though.
-- =

Rik Wasmus

Re: sessions and redirecting in opera

Rik wrote:
> On Mon, 13 Aug 2007 12:04:54 +0200, amygdala
> wrote:
>> Alright, this is strange:
>>
>> When I access my own example through a proxy (using the above url) it
>> works
>> as intended. Come to think of it, I do recall reading somewhere that
>> Opera
>> sometimes has problems with cookies when developing on a localhost
>> server.
>>
>> Are you aware of any such thing?
>
> Only domain conflicts if they aren't set properly :P

Hehe, no this should not be the cause of this, since I just set up this
temporarily subdomain (through DynDNS.com) pointing to my local webserver
today. Usually I only develop locally, through 127.0.0.1.

But anyway, thanks for the help Rik.

Re: sessions and redirecting in opera

Rik wrote:
> On Mon, 13 Aug 2007 12:33:20 +0200, amygdala
> wrote:
>> Rik wrote:
>>>> I've set up little example (without the echo part in the redirect
>>>> method) which you should be able to access temporarily through:
>>>>
>>>> http://amygdala.kicks-ass.net/profile/
>>>>
>>>> (Please let me know if you are not able to access it.)
>>>
>>> HTTP/1.x 302 Moved Temporarily
>>> ...
>>> Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
>>> Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
>>> Location: http://127.0.0.1/user/login/
>>> ...
>>>
>>> I haven't set up your site on my local box, so no, it's not working
>>> :).
>>
>> Errrr, sorry about that Rik, forgot to change
>>
>> define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );
>>
>> to
>>
>> define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );
>
> Ah, and everything works like a charm :P (allthough the double
> set-cookie PHPSESSID should be taken care of).

Well, this double Set-Cookie should indeed not be happening. Although I do
use session_regenerate_id() (paranoid mode ;) on every request. But I don't
suspect that that causes two set-cookie's in one response.

What kind of tool are you using to analyse/view this information if you
don't mind telling me? Is there any HTTPLiveHeader thingy for Opera I am not
aware of?

Thanks in advance

> So, possibly a server/domain issue somewhere when developing locally,
> works OK on the net though.

Looks like that is the case, yes.

Re: sessions and redirecting in opera

amygdala wrote:
> Jerry Stuckle wrote:
>> amygdala wrote:
>>> "Jerry Stuckle" schreef in bericht
>>> news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
>>>> amygdala wrote:
>>>>> Rik wrote:
>>>>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>>>>> wrote:
>>>>>>> Could it be that Opera needs some kind of body content after a
>>>>>>> redirection
>>>>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>>>>> should redirect back to the login page again, since it is
>>>>>>> redirected to a page, that redirected to the login page in the
>>>>>>> first place. lol
>>>>>> Possiblity 1:
>>>>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>>>>> Automatic Redirection.
>>>>>>
>>>>>> It's enabled by default, but can be disabled for whatever purpose.
>>>>>> All the more reason why a header redirect should be accompanied by
>>>>>> some information one is redirected, and a script should
>>>>>> die()/exit() after that.
>>>>>> Possibility 2:
>>>>>> Opera get's the redirect, but still has the page with the same
>>>>>> URL in cache, so decides to use that one. Set some header and/or
>>>>>> html information these pages should not be cached.
>>>>>>
>>>>>> Possibility 3:
>>>>>> The script isn't terminated after the first header-redirect,
>>>>>> continues to run, and effectively changes the redirect by a second
>>>>>> header() call. Putting an echo directly after it will force the
>>>>>> headers to be sent, so they cannot be replaced anymore, resulting
>>>>>> in the first one being the only one, and thus the one obeyed by
>>>>>> the browser. Another example why one should die()/exit() after a
>>>>>> redirect. >>>>>> //this will offcourse end in /second.html
>>>>>> header('Location: /first.html');
>>>>>> header('Location: /second.html');
>>>>>> >>>>>> //this will end in /first.html
>>>>>> header('Location: /first.html');
>>>>>> flush();
>>>>>> header('Location: /second.html');
>>>>> This thing still has me puzzled. What I did is the following:
>>>>>
>>>>> My SessionHandler class has the following method:
>>>>>
>>>>> public function redirect( $url )
>>>>> {
>>>>> session_write_close();
>>>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
>>>>> ); header( 'Cache-Control: no-store, no-cache, must-revalidate'
>>>>> ); header( 'Cache-Control: post-check=0, pre-check=0', false );
>>>>> header( 'Pragma: no-cache' );
>>>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>>>> header( 'Location: ' . $url );
>>>>> // this part between the comments is important
>>>>> echo 'You\'re being redirected to ' . $url . ' .
>>>>> Click if it doesn\'t work';
>>>>> // end important part
>>>>> exit(); // exit doesn't really make a difference for Opera
>>>>> }
>>>>>
>>>>> Since I have now included the exit() statement I am sure that this
>>>>> is the last thing done by the application when redirecting. Also,
>>>>> I have added cache control headers and the likes. But still in
>>>>> Opera the problem persists if I leave out the echo part you see
>>>>> above between the comments. So, from my experience it seems as if Opera
>>>>> wants some body
>>>>> content for the redirect to work and revalidate the url I landed
>>>>> on before I had to log in.
>>>>>
>>>>> Does anyone have any other clue as to what might be going on here?
>>>>>
>>>>> Thanks.
>>>> Why are you sending a message they will never see, anyway? Normally a
>>>> redirect header has NO text associated with it.
>>>>
>>>> If you have your header set up appropriately, they will be
>>>> redirected. All the message might do is screw things up for the
>>>> browser.
>>> PS.: Correct me if I'm wrong, but are my headers not set up properly?
>>>
>>>
>> Well, I don't see why you have the session_write_close() - the session
>> will be closed during exit() processing, anyway.
>>
>> I also don't see why you have all of the cache control stuff. It's
>> completely unnecessary in this case.
>>
>> Keep it simple - the 302 moved and location should be all you need.
>
> I would think so to, but if you have read the entire thread you would see
> that I am having trouble with getting it to work as expected in Opera. So I
> thought I'ld use every option at my disposal to make sure the redirect and
> the session saving works as expected.
>
> But now, it looks like the Opera problem only exists when accessing the
> application local on localhost. (See my reply to Rik)
>
>

Yes, I did read the entire thread. That's why I said it. Don't use
options just because they're there. Use them because there is a need
for them.

For instance - the cache control would have no effect on them, and using
them just complicates matters.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: sessions and redirecting in opera

Jerry Stuckle wrote:
> amygdala wrote:
>> Jerry Stuckle wrote:
>>> amygdala wrote:
>>>> "Jerry Stuckle" schreef in bericht
>>>> news:xqKdnb9U2fBnMyLbnZ2dnUVZ_uLinZ2d@comcast.com...
>>>>> amygdala wrote:
>>>>>> Rik wrote:
>>>>>>> On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>>>>>>> wrote:
>>>>>>>> Could it be that Opera needs some kind of body content after a
>>>>>>>> redirection
>>>>>>>> header? Or could it perhaps be that Opera indeed thinks that it
>>>>>>>> should redirect back to the login page again, since it is
>>>>>>>> redirected to a page, that redirected to the login page in the
>>>>>>>> first place. lol
>>>>>>> Possiblity 1:
>>>>>>> Opera -> Tools -> preferences -> Advanced -> Network -> Enable
>>>>>>> Automatic Redirection.
>>>>>>>
>>>>>>> It's enabled by default, but can be disabled for whatever
>>>>>>> purpose. All the more reason why a header redirect should be
>>>>>>> accompanied by some information one is redirected, and a script
>>>>>>> should die()/exit() after that.
>>>>>>> Possibility 2:
>>>>>>> Opera get's the redirect, but still has the page with the same
>>>>>>> URL in cache, so decides to use that one. Set some header and/or
>>>>>>> html information these pages should not be cached.
>>>>>>>
>>>>>>> Possibility 3:
>>>>>>> The script isn't terminated after the first header-redirect,
>>>>>>> continues to run, and effectively changes the redirect by a
>>>>>>> second header() call. Putting an echo directly after it will
>>>>>>> force the headers to be sent, so they cannot be replaced
>>>>>>> anymore, resulting in the first one being the only one, and
>>>>>>> thus the one obeyed by the browser. Another example why one
>>>>>>> should die()/exit() after a redirect. >>>>>>> //this will offcourse end in /second.html
>>>>>>> header('Location: /first.html');
>>>>>>> header('Location: /second.html');
>>>>>>> >>>>>>> //this will end in /first.html
>>>>>>> header('Location: /first.html');
>>>>>>> flush();
>>>>>>> header('Location: /second.html');
>>>>>> This thing still has me puzzled. What I did is the following:
>>>>>>
>>>>>> My SessionHandler class has the following method:
>>>>>>
>>>>>> public function redirect( $url )
>>>>>> {
>>>>>> session_write_close();
>>>>>> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
>>>>>> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
>>>>>> ); header( 'Cache-Control: no-store, no-cache, must-revalidate'
>>>>>> ); header( 'Cache-Control: post-check=0, pre-check=0', false );
>>>>>> header( 'Pragma: no-cache' );
>>>>>> header( 'HTTP/1.0 302 Moved Temporarily' );
>>>>>> header( 'Location: ' . $url );
>>>>>> // this part between the comments is important
>>>>>> echo 'You\'re being redirected to ' . $url . ' .
>>>>>> Click if it doesn\'t work';
>>>>>> // end important part
>>>>>> exit(); // exit doesn't really make a difference for Opera
>>>>>> }
>>>>>>
>>>>>> Since I have now included the exit() statement I am sure that
>>>>>> this is the last thing done by the application when redirecting.
>>>>>> Also,
>>>>>> I have added cache control headers and the likes. But still in
>>>>>> Opera the problem persists if I leave out the echo part you see
>>>>>> above between the comments. So, from my experience it seems as
>>>>>> if Opera wants some body
>>>>>> content for the redirect to work and revalidate the url I landed
>>>>>> on before I had to log in.
>>>>>>
>>>>>> Does anyone have any other clue as to what might be going on
>>>>>> here? Thanks.
>>>>> Why are you sending a message they will never see, anyway?
>>>>> Normally a redirect header has NO text associated with it.
>>>>>
>>>>> If you have your header set up appropriately, they will be
>>>>> redirected. All the message might do is screw things up for the
>>>>> browser.
>>>> PS.: Correct me if I'm wrong, but are my headers not set up
>>>> properly?
>>> Well, I don't see why you have the session_write_close() - the
>>> session will be closed during exit() processing, anyway.
>>>
>>> I also don't see why you have all of the cache control stuff. It's
>>> completely unnecessary in this case.
>>>
>>> Keep it simple - the 302 moved and location should be all you need.
>>
>> I would think so to, but if you have read the entire thread you
>> would see that I am having trouble with getting it to work as
>> expected in Opera. So I thought I'ld use every option at my disposal
>> to make sure the redirect and the session saving works as expected.
>>
>> But now, it looks like the Opera problem only exists when accessing
>> the application local on localhost. (See my reply to Rik)
>>
>>
>
> Yes, I did read the entire thread. That's why I said it. Don't use
> options just because they're there. Use them because there is a need
> for them.

I don't use them because they are there, I use them because every other
option in my mind was exhausted, so I thought I'ld give it a try and one by
one remove a header to see where the problem would arise in Opera. But I
started off putting them all in there for debugging purposes.

session_write_close(): because with Opera I was getting multiple session
entries in my DB. And I know this doesn't make sense logically (I can tell
client processes from server processes) and I know an exit() statement
should suffice, yada yada yada.

Cache-Control and other cache headers: because I thought Opera might somehow
not revalidate the initial redirected url.

But to tell you the truth, I don't see how any cache headers could harm:

header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );