Ask PG: Why the cookie change?

[DanielBMarkham]

Seems like in the last week or so, I keep having to go back to the login page. It didn't use to be that way.

It's annoying, and when you combine it with the new ClickPass option, it looks a lot like a "push" towards using that service.

Is there a technical reason for the new behavior? Is it related to the server slowness we had a while back? Apologies if somebody else has already asked this question.

[run4yourlives]

I'm pretty sure it's because they've been rebooting the server(s) more frequently. It's related to that slowness that we were experiencing the other day.

You'll notice that the first time you view your comments after a reboot, they get loaded into memory, and the page takes forever to load.

[pg]

We're trying to fix the slowness.

[icky → pg]

1. Stash key-value pairs in signed cookies (salt + text + sha1 should be fine; HMAC is even better-- I prefer a variant of HMAC where I concatenate the client's IP address onto the first hash before hashing again with the second key).

1a. Note that this only goes for key-value pairs you don't mind the user seeing, but want to keep tamper-proof. Real secret stuff still needs to be handled server-side.

2. Display them javascriptically, and only verify/change things server-side on login or POST. This lets you serve most pages as cached, static HTML!

2a. So if my username cookie is "[some 40-byte salted sha1hash]icky", then, client-side, I could change the username or the hash, and the page's javascript would display the new username for me (blindly chopping off the first 40 bytes that form the hash), but if I tried to post, then the server would detect the tampered cookie, and log me out. [Tampering with the display-name client-side is something you can already do with the Firebug or Web Developer plugins, so this really doesn't pose a problem].

3. When a POST happens, just regenerate the cached page that it dirtied, and dynamically serve it back to the poster.

4. That's it! You now have turned nearly all of your read-only requests into a static, cached page GET, which you can let Apache take care of without even hitting your application server.

[DanielBMarkham → icky]

icky -- don't know if you know it or not, but Paul's writing his own application language, Arc, and testing it out on this board.

To my knowledge he is not using an Apache stack. In addition, he's doing a keyed-continuations deal across loads/posts, so he's effectively keeping the stack around for each user.

Really cool stuff, but I can see where memory can become an issue. He's probably running into paging issues and trying this out as a fix.

At least I think that is the situation.

[icky → DanielBMarkham]

> icky -- don't know if you know it or not, but Paul's writing his own application language, Arc, and testing it out on this board.

"Whoa, you mean this isn't wood shop class?" ;-)

> To my knowledge he is not using an Apache stack.

For static pages, there's no reason he can't stick an Apache in front.

> In addition, he's doing a keyed-continuations deal across loads/posts, so he's effectively keeping the stack around for each user.

That part might be tricky to optimize, but there ought to be a way, even then, to avoid hitting the app server for static page loads.

Edit: Looking at the login cookie across page loads, it's just a session-id. There is absolutely no reason that the app server ever need know about these cached static page loads.

> Really cool stuff, but I can see where memory can become an issue. He's probably running into paging issues and trying this out as a fix.

He's also running into state issues, since he's keeping all session state as in-memory continuations, which is probably forcing him to keep news.yc on one box.

One thing that might work is to come up with a way to serialize those continuations, and store the key-value pairs in a memcached box. Then the app server can become stateless again, and he can add more boxes.

[TFrancis → icky]

> For static pages, there's no reason he can't stick an Apache in front.

For static pages, there no reason to stick Apache in front.

[icky → TFrancis]

> For static pages, there no reason to stick Apache in front.

Are you suggesting that static pages should hit the app server?

[TFrancis → icky]

No I'm suggesting that static content be served by something lighter than Apache.