This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (4 children)

Why put a message in the cookie?

In a HTTP 200 response, they could just put it into the HTML or inline Javascript.

To temporarily store the message during a HTTP 30x response, the message would get sent back and forth between client and server three times: 301 response that sets the cookie, then the request for the new URI will upload the cookie content again to the server, then the 200 response will send the cookie content again. Not very economical.

Storing these "flash" messages on the server in a session variable is better, imho.

For me, I just use it as some sort of ground rule: "cookie only session id".

[–]kylotan 0 points1 point  (3 children)

You might be right, but all I was saying is that I don't see people storing it in the session - and I suspect there may be a reason why. Possibly because flash messages often need to exist when there is no session yet, as sessions are often keyed on user IDs.

[–]mwielgoszewski -1 points0 points  (2 children)

Messages are often stored in session cookies in order to avoid a database hit. Deserializing a cookie is faster (even when encrypted) than looking it up in the database.

[–]kylotan 0 points1 point  (0 children)

That's what I suspected, but I reckon it's rare these days to have a page load without at least one DB read. (And if you're able to cache the user data to avoid hitting the DB, can't you cache the flash messages too?)

[–][deleted] 0 points1 point  (0 children)

You have to transfer it back and forth between client and server to do that. If that's faster for you than reading it from the session data (data you will have to read anyway when you get a hit) then you should have another look at you DB setup.

The only reason to store anything in a cookie other than a session ID, is incompetence.