Question about session cache response header

[pine3ree]

Hello,
in my tests as soon as session_start() is called, a response cache header is added, even if use_cookies is disabled. (I got the header already sent error while unit testing a project not based on expressive, but then I checked the response header of the skeleton application + session-ext and I noticed that a Pragma: no-cache header was automatically set)
Does this happen to anybody else?
Should we call session_cache_limiter(null) and programmatically add that header as it's already done for the session id cookie?

kind regards,
maks

[weierophinney]

I think that's probably a good idea, and may explain some issues I've seen when using this package.

If we do this, what header(s) should we add? The session_cache_limiter() allows four specific values, that set different combinations of headers. Do you feel this package suggests a single approach, or should we mimic session_cache_limiter and allow the user to configure which approach they wish to use?

[pine3ree]

Hello @weierophinney ,

I believe we should add the specific header just based on the current (pre-session-start) ini value of session.cache_limiter and storing that value as a configuration property of the persistence layer, before setting it to ''. (btw, we can simply add an extra cache_limiter option equal to the empty string, and avoid that function call)

Any custom cache limiter setting added via configuration before the pipeline is started would then be used like ext-session always did, but with a response header added by the persistence object. So it is just a change of responsibility (who's sending it) not of behaviour.

(I found it strange that you had problems though, since whether you are using php-session or this package, that (EDITED!!!cookie!!!NO, I MEANT =>) header is always sent (unless you are referring to headers already sent issues as in cli sapi). "php"'s default generic assumption is to send cache (or better no-cache) info if a page is generated while interacting with a user session)

I honestly never had the need to customize that value before and the utility function is very thorough https://github.com/php/php-src/blob/master/ext/session/session.c#L1095, but i believe that this package should just create and inject the header without adding any other specific tool, at least for now...

To keep it simple I see no reason for now to add custom ini constructor options for the persistence layer , but if we want to do that then we'll have to add mandatory settings check similar to: #11

kind regards,
maks

[weierophinney]

I found it strange that you had problems though, since whether you are using php-session or this package, that cookie is always sent

The issue I was having is that the cookie would expire every day, despite having set a largish session.lifetime value... which, when I look at the source code now, we never pass on to the cookie we're creating. So that's a separate issue.

[pine3ree]

...the session-name cookie?

if (empty($this->cookie)) {
//...add the session-name cookie header

to

if (empty($this->cookie)) {
    $this->cookie = session_id(); // (..)_id of course....
}
// add the session cookie header if $this->cookie === session_id() is not empty (edited)

?

(edited)
the session-name cookie must be sent anyway if a session is started so that the expiry time is refreshed on the client.
..."bad things" can happen before the emitter sends the response, in that case fresh session data is not persisted and the session-name cookie header not sent.
This happens also when you do:

header ('Location: /new-url');

instead of returning a redirect response....

[pine3ree]

The cache header generation is actually a bit less trivial:

1. with session.cache_limiter === '' no cache headers are added
2. with session.cache_limiter === nocache I get 3 headers:

Cache-Control: no-store, no-cache, must-revalidate
Expires:       Thu, 19 Nov 1981 08:52:00 GMT (fixed past date)
Pragma:        no-cache (HTTP/1.0 compatibility)

3. with session.cache_limiter === public (or private) I get 3 headers:

Cache-Control: public(or private), max-age=7200 (session.cache_expire * 60 === converted to seconds)
Expires:       Mon, 23 Apr 2018 22:00:32 GMT (now + session.cache_expire GMT)
Last-Modified: Mon, 23 Apr 2018 19:00:29 GMT (request date GMT *** nope**script modified time)

4. with session.cache_limiter === private_no_expire I get 2 headers:
   same as previous case without the Expires header

[pine3ree]

@weierophinney
sorry, there was a typo in my text, I noticed it only after your answer....

that cookie is always sent

was meant to be

that header is always sent

and i was referring to the automatically added cache header
kind regards!

[pine3ree]

Update: I am trying to build the functionality for intercepting the cache_limiter and add the cache headers to the response by inspecting the php-src: I juts found-out that the Last-Modified header is actually the GMT modified time of the running script:

https://github.com/php/php-src/blob/PHP-7.1.17/ext/session/session.c#L1090
https://github.com/php/php-src/blob/PHP-7.1.17/ext/session/session.c#L1098

[pine3ree]

this could be the first step of a possible implementation: #12