Remove context header for anonymous users

[ddeboer]

From #180:

The hash request is only ever executed when there is a cookie / auth header: https://github.com/FriendsOfSymfony/FOSHttpCache/blob/master/tests/Functional/Fixtures/varnish-3/user_context.vcl#L16

The Vary information also includes the variant of not having the header in question.

I think we can close #132 and think whether we should remove the corresponding code in the SymfonyCache and just have no context header. https://github.com/FriendsOfSymfony/FOSHttpCache/blob/master/src/SymfonyCache/UserContextSubscriber.php#L165 - the backend certainly should not use the hash, but only Vary on it.

[ddeboer]

Sounds like a good idea to me!

@lolautruche Do you agree (based on your comments in #132)?

[dbu]

would make sense to me.

[dbu]

@lolautruche wdyt?

the alternative scenario would be to actually go to the backend even without cookie (only once, then that hash is cached too) in case there might be a session for non-logged-in users or even logged in users that belong to the same group as anonymous users. with the manual hash, we split this group.

[ddeboer]

We should remember that Symfony/Silex currently automatically creates a session, and thus a PHPSESSID cookie. This means that even for anonymous users a Cookie header will be present and (according to our Varnish config) the hash lookup will take place.

@dbu There’s been some discussion about this, and if I’m not mistaken you were part of that. Do you know which decisions have been reached concerning Symfony’s behaviour?

[dbu]

There is a cookbook entry on how to avoid session in symfony. I think the check would just be a shortcut for when no session for anonymous. We can document it like that - if you do session for anonymous, its just useless overhead.

I think it will never create a problem - unless you ignore but use basic auth, or some custom authentication system without cookies...

[lolautruche]

@ddeboer Symfony doesn't automatically create a session. It does when using dev environment (profiler).

the alternative scenario would be to actually go to the backend even without cookie (only once, then that hash is cached too) in case there might be a session for non-logged-in users or even logged in users that belong to the same group as anonymous users.

@dbu If there is a session (even anonymous), we always go to the backend. This is the only possible discrimination. As for authenticated users who belong to the same group as anonymous users, we don't split them. It's just that they will go to the backend for them as they do have a session.

TBH, I don't see any benefit of removing the hash for anonymous users.

[dbu]

ok i was confusing. my point was that maybe the backend could decide on giving the same hash when there is no session as when there is session for anonymous as when i am a authenticated but limited user.

i think the developer has two options:

• prevent going to the backend when there is no session. whether we hardcode a header or not set a header at all makes technically no difference. my suggestion was to remove the header in this case as it has no meaning.
• still go to the backend for hash lookup. this should be only one request which is then cached, so the performance impact should be extremly small (unless hash lookups are not cached)

given that, i actually think that we should by default always go to the backend for the hash lookup. it removes one potential WTF at the cost of 1 request per hour or less.

[dbu]

btw, regarding sessions in symfony, there is http://symfony.com/doc/current/cookbook/session/avoid_session_start.html

[dbu]

given that, i actually think that we should by default always go to the backend for the hash lookup.
it removes one potential WTF at the cost of 1 request per hour or less.

@ddeboer @lolautruche as we are talking about tagging 1.4 - what about this one? would be nice to decide before we release.

at the same time we can explain how to avoid the call to the backend with varnish if not needed. that is just documentation, no actual code as its all in vcl.

[ddeboer]

I decided not to wait with 1.4 until this is solved.

[dbu]

agreed. i will create a version 2 milestone and add this issue to it as we should clean things up for 2.0 (there is some wtf potential here - both with the current behaviour but also of course when changing default behaviour)

[dbu]

@lolautruche we are slowly thinking of wrapping up a 2.0 of this library. what do you think of this? i think the cleanest would be to always do a request for the hash, even when its an anonymous user. the hash requests are cached so it costs very little and avoids some confusion. does that make sense to you?

whichever we go, i would love to make varnish and httpcache consistent in this.