Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #5494 > unrolled thread

session question

Back to article view | Back to comp.lang.php

Contents

  session question William Gill <noreply@domain.invalid> - 2012-04-12 12:43 -0400
    Re: session question Scott Johnson <noonehome@chalupasworld.com> - 2012-04-12 09:56 -0700
    Re: session question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 19:43 +0200
    Re: session question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 19:59 +0200
    Re: session question Captain Paralytic <paul_lautman@yahoo.com> - 2012-04-13 02:18 -0700
    Re: session question Denis McMahon <denismfmcmahon@gmail.com> - 2012-04-13 13:27 +0000
      Re: session question William Gill <noreply@domain.invalid> - 2012-04-13 13:51 -0400
        Re: session question Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-13 15:54 -0400
        Re: session question William Gill <nospam@domain.invalid> - 2012-04-20 02:40 -0400
          Re: session question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-20 10:55 +0200
          Re: session question Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-04-20 11:25 +0200
          Re: session question Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 08:11 -0400
            Re: session question William Gill <noreply@domain.invalid> - 2012-04-20 10:59 -0400
              Re: session question William Gill <noreply@domain.invalid> - 2012-04-20 11:32 -0400
              Re: session question Michael Fesser <netizen@gmx.de> - 2012-04-20 17:50 +0200
                Re: session question William Gill <nospam@domain.invalid> - 2012-04-20 12:04 -0400
                  Re: session question Tim Streater <timstreater@greenbee.net> - 2012-04-20 18:17 +0100
                    Re: session question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-20 20:08 +0200
                      Re: session question Tim Streater <timstreater@greenbee.net> - 2012-04-20 20:36 +0100
                        Re: session question William Gill <nospam@domain.invalid> - 2012-04-21 18:13 -0400
                  Re: session question Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 14:22 -0400
                    Re: session question William Gill <nospam@domain.invalid> - 2012-04-20 15:04 -0400
                      Re: session question The Natural Philosopher <tnp@invalid.invalid> - 2012-04-20 22:09 +0100
                    Re: session question Michael Fesser <netizen@gmx.de> - 2012-04-20 21:13 +0200
                      Re: session question Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 15:45 -0400
                        Re: session question Tim Streater <timstreater@greenbee.net> - 2012-04-20 23:11 +0100
                          Re: session question The Natural Philosopher <tnp@invalid.invalid> - 2012-04-20 23:23 +0100
                            Re: session question Tim Streater <timstreater@greenbee.net> - 2012-04-21 13:14 +0100
                          Re: session question Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-20 18:45 -0400
                          Re: session question Michael Fesser <netizen@gmx.de> - 2012-04-21 01:24 +0200
                            Re: session question The Natural Philosopher <tnp@invalid.invalid> - 2012-04-21 01:28 +0100

Page 1 of 2  [1] 2  Next page →

#5494 — session question

I have a site with an input form that recursively calls itself via 
action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with 
url encoded data that indicate simple selections w/o using a form.  It 
uses different  include('file'); statements based on the progress and/or 
choices previously made, and it works fine, but is a little complicated 
to track "state" when troubleshooting, updating, or changing.

I am thinking of using a session approach which would be simpler to 
follow, but have never used sessions on a page that is recursively called.

First since session_start() would be called every iteration, that will 
cause an error unless I encapsulate it in an if loop to see if the 
session already exists.  Is this the preferred method?

Second, when the user is finished and receives an acknowledgement I plan 
to call a session_unset() to clear things up so that if they want to do 
it again, they are beginning with a clean slate. Again, is this the 
preferred method?

[toc] | [next] | [standalone]

#5495

On 4/12/2012 9:43 AM, William Gill wrote:
> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with
> url encoded data that indicate simple selections w/o using a form. It
> uses different include('file'); statements based on the progress and/or
> choices previously made, and it works fine, but is a little complicated
> to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively called.
>
> First since session_start() would be called every iteration, that will
> cause an error unless I encapsulate it in an if loop to see if the
> session already exists. Is this the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan
> to call a session_unset() to clear things up so that if they want to do
> it again, they are beginning with a clean slate. Again, is this the
> preferred method?
>
>

You won't get an error for calling session_start on a page that calls 
itself 'unless' you have it being called multiple times such as in one 
of your include files.

Each call to that page whether it is from another page or itself is a 
separate new call to that page and the session_start does not carry over.

Do not use session_unset unless you are on an old PHP install (4) i 
think, in which case get it updated

use the unset() method.

But I would not use that solely.

I personally empty each $_SESSION variable
with $_SESSION = array();

I guess you could use session_destroy() but I have not used this and am 
not sure how it behaves.

Sure someone will have some more info on this.

[toc] | [prev] | [next] | [standalone]

#5499

Am 12.04.2012 18:43, schrieb William Gill:
> I have a site with an input form that recursively calls itself via action="<?php echo
> $_SERVER['PHP_SELF']; ?>", and a couple links with url encoded data that indicate
> simple selections w/o using a form.  It uses different  include('file'); statements
> based on the progress and/or choices previously made, and it works fine, but is a
> little complicated to track "state" when troubleshooting, updating, or changing.
> 
> I am thinking of using a session approach which would be simpler to follow, but have
> never used sessions on a page that is recursively called.
> 
> First since session_start() would be called every iteration, that will cause an error
> unless I encapsulate it in an if loop to see if the session already exists.  Is this
> the preferred method?
> 
> Second, when the user is finished and receives an acknowledgement I plan to call a
> session_unset() to clear things up so that if they want to do it again, they are
> beginning with a clean slate. Again, is this the preferred method?
> 

call session_start() at the beginning of your script.

Do not use session_unset(), it is old as Scott said. Assign null to your session
variables, or unset() them, but do not unset($_SESSION)

See
http://groups.google.com/group/comp.lang.php/browse_thread/thread/8b3b25491e095a49/76d6a3eeb680f503

there is an example of session usage.

[toc] | [prev] | [next] | [standalone]

#5500

Am 12.04.2012 18:43, schrieb William Gill:
> I have a site with an input form that recursively calls itself via action="<?php echo
> $_SERVER['PHP_SELF']; ?>", and a couple links with url encoded data that indicate
> simple selections w/o using a form.  It uses different  include('file'); statements
> based on the progress and/or choices previously made, and it works fine, but is a
> little complicated to track "state" when troubleshooting, updating, or changing.
> 
> I am thinking of using a session approach which would be simpler to follow, but have
> never used sessions on a page that is recursively called.
> 
> First since session_start() would be called every iteration, that will cause an error
> unless I encapsulate it in an if loop to see if the session already exists.  Is this
> the preferred method?
> 
> Second, when the user is finished and receives an acknowledgement I plan to call a
> session_unset() to clear things up so that if they want to do it again, they are
> beginning with a clean slate. Again, is this the preferred method?
> 
> 

... and look up all the functions you want to use in the manual, read down to "See
Also", and read them as well.

/Str.

[toc] | [prev] | [next] | [standalone]

#5509

On Apr 12, 5:43 pm, William Gill <nore...@domain.invalid> wrote:
> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with
> url encoded data that indicate simple selections w/o using a form.  It
> uses different  include('file'); statements based on the progress and/or
> choices previously made, and it works fine, but is a little complicated
> to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively called.
>
> First since session_start() would be called every iteration, that will
> cause an error unless I encapsulate it in an if loop to see if the
> session already exists.  Is this the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan
> to call a session_unset() to clear things up so that if they want to do
> it again, they are beginning with a clean slate. Again, is this the
> preferred method?

Your form is not recursive. When it is displayed the php script is
completed. The next time it is submitted it is treated as a new
process.

[toc] | [prev] | [next] | [standalone]

#5515

On Thu, 12 Apr 2012 12:43:28 -0400, William Gill wrote:

> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>"

Nope. Recursive is the wrong term to use here. It calls itself, yes, but 
does not do so in a truly recursive manner.

> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively
> called.

This is not recursive calling. In recursive calling, a function calls 
itself from within itself.

In a web page that includes a link back to itself, it has completed all 
processing before it is called again.

Just include a single call to session_start() at the start of the main php 
script file, and don't call it on the included php script files.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#5520

On 4/13/2012 9:27 AM, Denis McMahon wrote:
> Nope. Recursive is the wrong term to use here. It calls itself, yes, but
> does not do so in a truly recursive manner.
>
>> I am thinking of using a session approach which would be simpler to
>> follow, but have never used sessions on a page that is recursively
>> called.
>
> This is not recursive calling. In recursive calling, a function calls
> itself from within itself.
>
> In a web page that includes a link back to itself, it has completed all
> processing before it is called again.
>
> Just include a single call to session_start() at the start of the main php
> script file, and don't call it on the included php script files.

Though I agree with your definition of recursive calling of a function, 
I'm not sure the term recursive is limited to functions.  However maybe 
repetitively would have been a better choice.

To clear up some things for some of the other respondents, the page gets 
called several ways.

1) The initial GET domain/page.php which includes() an intro and list of 
links.

2) A second GET from one of the links:
<a href="<?php echo $_SERVER['PHP_SELF'] ?>?whoDoYouWantToContact=John">
which then includes() the HTML form.

3) A POST from the form:
<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post" >
which then includes() a process the form script and an acknowledgement 
that the data was received.

Denis, my testing confirms that you are correct, placing the 
session_start() on the core page does not produce errors on subsequent 
GETS or POSTS.  Which makes logical sense, but seemed to conflict with 
the manual. Thanks, helping clear that up.

[toc] | [prev] | [next] | [standalone]

#5521

On 4/13/2012 1:51 PM, William Gill wrote:
> On 4/13/2012 9:27 AM, Denis McMahon wrote:
>> Nope. Recursive is the wrong term to use here. It calls itself, yes, but
>> does not do so in a truly recursive manner.
>>
>>> I am thinking of using a session approach which would be simpler to
>>> follow, but have never used sessions on a page that is recursively
>>> called.
>>
>> This is not recursive calling. In recursive calling, a function calls
>> itself from within itself.
>>
>> In a web page that includes a link back to itself, it has completed all
>> processing before it is called again.
>>
>> Just include a single call to session_start() at the start of the main
>> php
>> script file, and don't call it on the included php script files.
>
> Though I agree with your definition of recursive calling of a function,
> I'm not sure the term recursive is limited to functions. However maybe
> repetitively would have been a better choice.
>
> To clear up some things for some of the other respondents, the page gets
> called several ways.
>
> 1) The initial GET domain/page.php which includes() an intro and list of
> links.
>
> 2) A second GET from one of the links:
> <a href="<?php echo $_SERVER['PHP_SELF'] ?>?whoDoYouWantToContact=John">
> which then includes() the HTML form.
>
> 3) A POST from the form:
> <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post" >
> which then includes() a process the form script and an acknowledgement
> that the data was received.
>
> Denis, my testing confirms that you are correct, placing the
> session_start() on the core page does not produce errors on subsequent
> GETS or POSTS. Which makes logical sense, but seemed to conflict with
> the manual. Thanks, helping clear that up.
>
>

William, Denis is correct.  You are not calling the page recursively.

Recursive is when something calls itself without terminating.  Web 
scripts are transactional in nature - the first script finishes before 
the page is ever presented to the user.  So when the user clicks on a 
link (or whatever) to request the next page, a brand new request starts 
out.  Nothing is left over from the previous request except what is sent 
in the GET/POST parameters and cookies.

Note that saving data on the server in the $_SESSION still requires the 
session ID to be sent in one of the above parameters so you can save 
additional data on the server, but this is just to make things easier on 
the programmer.

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

[toc] | [prev] | [next] | [standalone]

#5576

On 4/13/2012 1:51 PM, William Gill wrote:

> ...my testing confirms that you are correct, placing the
> session_start() on the core page does not produce errors on subsequent
> GETS or POSTS. Which makes logical sense, but seemed to conflict with
> the manual. Thanks, helping clear that up.
>
After all this, I move the pages from a Windows development server to a 
Linux production server and even though <?php session_start(); ?> is 
before the DOCTYPE declaration I get "Cannot send session cache limiter 
- headers already sent..."

Only way that got rid of the error was to use an .htaccess file to auto 
start sessions for that folder.

[toc] | [prev] | [next] | [standalone]

#5586

Am 20.04.2012 08:40, schrieb William Gill:
> On 4/13/2012 1:51 PM, William Gill wrote:
> 
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a Linux
> production server and even though <?php session_start(); ?> is before the DOCTYPE
> declaration I get "Cannot send session cache limiter - headers already sent..."
> 
> Only way that got rid of the error was to use an .htaccess file to auto start
> sessions for that folder.

The error is in your PHP file.

There is definitely no need to use a .htaccess file to start a session. Not "even" on
a *nix system, which is the home of web servers, php and the complete internet.

/Str.

[toc] | [prev] | [next] | [standalone]

#5589

On 4/20/2012 8:40 AM, William Gill wrote:
> On 4/13/2012 1:51 PM, William Gill wrote:
>
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a
> Linux production server and even though <?php session_start(); ?> is
> before the DOCTYPE declaration I get "Cannot send session cache limiter
> - headers already sent..."
>
> Only way that got rid of the error was to use an .htaccess file to auto
> start sessions for that folder.
>
>

Hi,

That error means you DID send output before calling session_start().
Try to figure out if you are including anything before that line that 
might produce the output, even a SPACE or NEWLINE is output.

I do sometimes use the .htaccess to autostart sessions for a folder: it 
is convenient in some situations: nothing wrong with that.
But you better try to find out WHAT is producing output before your 
session_start() call.

I would start with:
1) replace the session_start() call with
echo "**TESTING**";
2) Check the output to your browser and see what appears before 
**TESTING**, and from there try to figure out what is responsible for 
the output before **TESTING**.


Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#5594

On 4/20/2012 2:40 AM, William Gill wrote:
> On 4/13/2012 1:51 PM, William Gill wrote:
>
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a
> Linux production server and even though <?php session_start(); ?> is
> before the DOCTYPE declaration I get "Cannot send session cache limiter
> - headers already sent..."
>
> Only way that got rid of the error was to use an .htaccess file to auto
> start sessions for that folder.
>
>

Horse hockey.  Fix your code and the problem will go away.

The ONLY reason you get that message is because you've already sent SOME 
output to the client.  It could be a DOCTYPE, white space or any of a 
number of things.  But SOMETHING caused the output to be sent.

And if you look at the following message it should tell you exactly 
where that output came from.

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

[toc] | [prev] | [next] | [standalone]

#5597

On 4/20/2012 4:55 AM, M. Strobel wrote:
 >
 > The error is in your PHP file.
 >

On 4/20/2012 8:11 AM, Jerry Stuckle wrote:
> Horse hockey. Fix your code and the problem will go away.
>
> The ONLY reason you get that message is because you've already sent SOME
> output to the client. It could be a DOCTYPE, white space or any of a
> number of things. But SOMETHING caused the output to be sent.
>
> And if you look at the following message it should tell you exactly
> where that output came from.
>

I know what the documentation says, and I know what's actually 
happening.  I have checked "my code"

from the test page:


<?php session_start(); ?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

the first 5 characters in the file are "<?php".

I will pursuing it with the semi-nitwits my hosting company calls 
"support."

In the mean time I was hoping someone might look past the knee-jerk "You 
f'ed up" response (my initial response too), and give me a clue how or 
why something is being output before it's supposed to be. I'd be open to 
suggestions how to test what and when the server sends.

I guess I can use telnet to see what the server is sending.

Erwin,

I can't echo anything before the DOCTYPE declaration, and anything 
visible would be long after the headers were sent, but thanks.

[toc] | [prev] | [next] | [standalone]

#5599

On 4/20/2012 10:59 AM, William Gill wrote:
> I will pursuing ...

meant to change tense from am pursuing to will pursue.  I sometimes type 
faster than I think, and I type very slowly.

[toc] | [prev] | [next] | [standalone]

#5600

.oO(William Gill)

>I know what the documentation says, and I know what's actually 
>happening.  I have checked "my code"
>
>from the test page:
>
>
><?php session_start(); ?>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>  "http://www.w3.org/TR/html4/strict.dtd">
>
>the first 5 characters in the file are "<?php".

Are you using UTF-8? Then there might be a BOM at the very beginning of
the file.

Micha

-- 
http://mfesser.de/blickwinkel

[toc] | [prev] | [next] | [standalone]

#5601

On 4/20/2012 11:50 AM, Michael Fesser wrote:
> .oO(William Gill)
>
>> I know what the documentation says, and I know what's actually
>> happening.  I have checked "my code"
>>
>>from the test page:
>>
>>
>> <?php session_start(); ?>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>>   "http://www.w3.org/TR/html4/strict.dtd">
>>
>> the first 5 characters in the file are "<?php".
>
> Are you using UTF-8? Then there might be a BOM at the very beginning of
> the file.
>
> Micha
>
And we have a winner ladies and gentlemen!

Thank you very much Micha, at my age pulling my hair out isn't recommended.

[toc] | [prev] | [next] | [standalone]

#5602

In article <jms1ef$h74$1@dont-email.me>,
 William Gill <nospam@domain.invalid> wrote:

> On 4/20/2012 11:50 AM, Michael Fesser wrote:
> > .oO(William Gill)
> >
> >> I know what the documentation says, and I know what's actually
> >> happening.  I have checked "my code"
> >>
> >>from the test page:
> >>
> >>
> >> <?php session_start(); ?>
> >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> >>   "http://www.w3.org/TR/html4/strict.dtd">
> >>
> >> the first 5 characters in the file are "<?php".
> >
> > Are you using UTF-8? Then there might be a BOM at the very beginning of
> > the file.
> >
> > Micha
> >
> And we have a winner ladies and gentlemen!
> 
> Thank you very much Micha, at my age pulling my hair out isn't recommended.

Thus illustrating why it's *not* a good idea to save UTF-8 files with 
BOM.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5603

Am 20.04.2012 19:17, schrieb Tim Streater:
> In article <jms1ef$h74$1@dont-email.me>,
> William Gill <nospam@domain.invalid> wrote:
> 
>> On 4/20/2012 11:50 AM, Michael Fesser wrote:
>> > .oO(William Gill)
>> >
>> >> I know what the documentation says, and I know what's actually
>> >> happening.  I have checked "my code"
>> >>
>> >>from the test page:
>> >>
>> >>
>> >> <?php session_start(); ?>
>> >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>> >>   "http://www.w3.org/TR/html4/strict.dtd">
>> >>
>> >> the first 5 characters in the file are "<?php".
>> >
>> > Are you using UTF-8? Then there might be a BOM at the very beginning of
>> > the file.
>> >
>> > Micha
>> >
>> And we have a winner ladies and gentlemen!
>>
>> Thank you very much Micha, at my age pulling my hair out isn't recommended.
> 
> Thus illustrating why it's *not* a good idea to save UTF-8 files with BOM.

Your editor does it for you, you won't see it. The same problem comes up in other
programming languages.

Programs - Webserver, PHP - must adapt to it, it is a legal sign.

/Str.

[toc] | [prev] | [next] | [standalone]

#5609

In article <9vdn1dFc36U1@mid.uni-berlin.de>,
 "M. Strobel" <sorry_no_mail_here@nowhere.dee> wrote:

> Am 20.04.2012 19:17, schrieb Tim Streater:
> > In article <jms1ef$h74$1@dont-email.me>,
> > William Gill <nospam@domain.invalid> wrote:

> >> And we have a winner ladies and gentlemen!
> >>
> >> Thank you very much Micha, at my age pulling my hair out isn't 
> >> recommended.
> > 
> > Thus illustrating why it's *not* a good idea to save UTF-8 files with BOM.
> 
> Your editor does it for you, you won't see it. The same problem comes up in 
> other programming languages.
> 
> Programs - Webserver, PHP - must adapt to it, it is a legal sign.

I Use TextWrangler on a Mac. It, and BBedit, give me the choice to set a 
default of how to save files, in the Prefs. So I choose UTF-8. In fact, 
the authors are so well aware that the BOM is a pain in the dong, that 
you have to explicitly ask for UTF-8,BOM in order to have it. They 
changed the defaults this way a few years back.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5641

On 4/20/2012 3:36 PM, Tim Streater wrote:
> I Use TextWrangler on a Mac. It, and BBedit, give me the choice to set a
> default of how to save files, in the Prefs. So I choose UTF-8. In fact,
> the authors are so well aware that the BOM is a pain in the dong, that
> you have to explicitly ask for UTF-8,BOM in order to have it. They
> changed the defaults this way a few years back.
>
I use a couple different text editors, and some add it quietly w/o 
notice, and some give you the option.  It's never been an issue until 
this so I never gave it a second thought.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web