Because of the state information associated with logins, A Web server has a limited number of login connections it can handle. You're making excuses for a part

Because of the state information associated with logins, A Web server has a limited number of login connections it can handle. You're making excuses for a particular setup - this is not something which holds true of all web servers. It's quite possible to store the state necessary to allow 10000 simultaneous logins if you use cookies and a db to store your state, rather than relying on in-memory state and fragile continuation links like this (created a few minutes ago): https://news.ycombinator.com/x?fnid=l5qgIWgvnRbHE7owLEaPMw https://news.ycombinator.com/x?fnid=l5qgIWgvnRbHE7owLEaPMw or tying replies to stored state on the server which expires within minutes. Many large scale sites manage it, I suppose because they don't store data like this in memory or urls. I'm not sure about this idea of storing state in urls, it often backfires, and urls should identify resources and actions, not store state. There is no good reason the server cannot receive a POST request from an authenticated user against a node id, and perform the requested action (post my reply please), no matter how many intervening logins/actions it has handled. Looking at the form in question (reply forms) reveals why it does break: <input type="hidden" name="fnid" value="UswPVmT3a8lZnqPBtcx359"> The server stores a continuation in the comment reply form, which (like the more link above) expires very quickly. The reason it expires is presumably because the server keeps a list of these fnids in memory, and as you say the list is finite, but it doesn't have to do that. There are other ways to create a CSRF (if that's what they use this for) which won't expire so quickly, and this problem is not one which many sites experience. It is annoying just how quickly reply links, more links etc expire on this site, and if the site used a different method to sign reply forms or construct other links they could get rid of this issue. Keeping data in memory like this will become more and more of a problem as the site scales - eventually things would break in seconds with enough load - that's clearly not acceptable.