Do some operation just before sending response header

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View


Is it possible to `hook' some operation before sending response
I want to build a certain cookie and add it to response header
at the time when response header is sent.

What I want to do

I'm trying to store session data into cookie, not local file.
I want to serialize $_SESSION data and store it to cookie,
and it should be done at when sending response headers.

I don't want to change my PHP code very much. For example,
adding '<?php store_session_into_cookie(); ?>' for each file
is not the solution what I want.

What I tried

I tried to use session_set_save_handler().

   session_set_save_handler("_open", "_close", "_read", "_write",
"_destroy", "_gc");

But _write() callback is called after content is sent.
It means that it is impossible to add cookie in _write() callback.

Therefore, I seek a hook or trigger function which is invoked before
sending response header.



Re: Do some operation just before sending response header

Ko Omura wrote:
Quoted text here. Click to load it

Well, that is the way the cookie thingy works.

If you really need cookies you have to do this the way as the php documentation

Once the cookies have been set, they can be accessed on the next page load with
the $_COOKIE or $HTTP_COOKIE_VARS arrays. Note, superglobals  such as $_COOKIE
became available in PHP 4.1.0. Cookie values also exist in $_REQUEST.

johannes ke├čler

Re: Do some operation just before sending response header

Quoted text here. Click to load it

Of course. You can add headers, set cookies, and just about anything
that doesn't involve sending any of the body to the client. You can
even write output to the body but defer sending it using output

Quoted text here. Click to load it

This is very dangerous. Although (IIRC) the HTTP rfcs do not place an
upper limit on the size of cookies, most web browsers do (4096 bytes).
How do you ensure that the session is not being truncated/invalidated/
corrupted as a result?

Also, you are allowing the client unrestricted access to modify the
contents of the session itself rather than validating and controlling
all changes to it. i.e. if you have any security restrictions /
integrity controls implemented via the session they will be
ineffective as a result.

There is nothing to prevent you from completing all the updates to the
session before starting to send the body to the client (and hence
creating a cookie first) but it's a really bad idea to push the
session data back to the client at all, and a worse idea to try to do
it in a cookie.


Site Timeline