ID:               14255
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Feedback
+Status:           No Feedback
 Bug Type:         HTTP related
 Operating System: Debian 2.2.19
 PHP Version:      4.0.6
 Assigned To:      shiflett
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:
------------------------------------------------------------------------

[2002-02-06 14:00:02] [EMAIL PROTECTED]

I'm changing the category to HTTP and status to feedback. I do not think
this is a bug but want to give the submitter time to respond to my
inquiry.

------------------------------------------------------------------------

[2002-02-06 12:33:40] [EMAIL PROTECTED]

Is this even a bug?  It's under documentation problem.  Do I need to
change something in the documentation?


------------------------------------------------------------------------

[2002-02-03 22:47:01] [EMAIL PROTECTED]

A couple of comments.

Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code
will fail because you cannot set a cookie and give a Location header in
the same HTTP response. Well, you *can*, but your cookie will not be
set. Since the server would not be able to identify the client without
the cookie, you get the unexpected behavior. This is a protocol-level
situation, but is generally *not* considered a bug in HTTP (in case you
got the feeling I was supporting that idea). Basically, PHP gives you
the freedom to specify your own headers in the HTTP response, but you
need to have a clear grasp of what they do to use them.

So, if this example was a clear illustration of the problem you've been
having, it's not a bug in PHP. You can spread that around to others who
are having the same problems.

Also, in regards to the time/date discussion, it is correct to say that
the browser uses the client time (obviously) to determine whether to
send a cookie along with subsequent HTTP requests. It is also correct to
say that the setcookie function uses the server time to set the
expiration date. However, since both are in GMT as [EMAIL PROTECTED]
explained (sorry, I don't know your name), this only matters if both
clocks are considerably out of sync or if the expiration time of the
cookie is extremely small. If this is a concern, consider using
client-side scripting to set the cookie, so that the browser itself
creates the cookie based on its own time. You can create the client-side
script itself using PHP, so that the cookie's value can still be
dynamically generated by your PHP scripts.

Hope that clears a few things up. If this didn't solve your problem,
please post another small example, and I'll try to reproduce your
environment.

------------------------------------------------------------------------

[2001-12-05 06:52:05] [EMAIL PROTECTED]

Timezones do NOT matter. All times are GMT.
>From a HTTP-response: 
Set-Cookie: CookieName=CookieValue; expires=Mon, 28-Jan-02 00:47:45
GMT
So the only thing that should be noted is that the time on client and
server should be in sync for correct behaviour.

------------------------------------------------------------------------

[2001-11-28 04:39:25] [EMAIL PROTECTED]

ok, stupid me regarding the claim that a zero value
(or a string as parameter, evaluating to zero)
actualy deletes a cookie

it indeed defines the cookie to be a session cookie
which is valid until the browser is closed instead
of until a certain date/time is reached

for the time parameter itself:
the time() function returns the server time
while the browser deciedes when to delete
a cookie by the client time

if client and server are not in sync or live in
different time zones you will get exactly the 
problems you experienced

you either have to use expiration times in the range of days isntead of
hours (as timezone differences can sum up to slightly more than 24 hours
in the worst case) or you have to use javascript Date.getTime() to fetch
the client time and transfer it to the server as a base for expiration
dates instead of using the time() function on the server

(will add a note to the setcookie documentation and work through the
notes later, bug type switched to documentation problem for now)


------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/14255

-- 
Edit this bug report at http://bugs.php.net/?id=14255&edit=1

Reply via email to