31–40 of 142 posts
You get that when your session expires, which takes just slightly less time than writing a well thought out comment.
The first complaints are from 1575 days (over 4 years) ago, including about the more button breaking, so I am guessing pg has no interest in fixing it.
Hacker News is open source, so it seems as if nobody is interested in fixing it. Or are there fixes and pg has rejected them?
The HN server uses a table of closures to implement those links (the id code for the closure is the bit after fnid= in the url). When the HN server starts running out of memory, it drops entries from this table. When your browser asks for an entry that is no longer in this table, you get the "Unknown or expired link" error. This is a crazy design, but unless someone would like to patch the source code and get PG to a…
It's not crazy at all, it greatly simplifies development to use callbacks for actions rather than manually encoding the necessary state into the URL. Techniques such as this are what enable a single developer to be so productive by automating boring and time consuming stuff.
Building broken software is always much easier than building robust correct software so this is hardly a good argument.
Earlier quoted context omitted.
It's not crazy at all, it greatly simplifies development to use callbacks for actions rather than manually encoding the necessary state into the URL. Techniques such as this are what enable a single developer to be so productive by automating boring and time consuming stuff.
Except it doesn't appear to work robustly, which makes it poor design. "Automating boring and time consuming stuff," is all well and good if it actually produces a functional system, but that concern is secondary to robustness.
In other words, there's a problem here, but it's not the programming model that pg chose.
I thought this was to combat cross-site request forgery attacks? Else couldn't one set up malicious scripts to up-or downvote many stories, or post comments under someone else's name?
Earlier quoted context omitted.
You don't want to execute code from URLs. (Yes, you can use cryptography to "sign" URLs you create. Don't try that at home unless you know the difference between MACs and hashes, and how to avoid timing attacks.)
Whoa, whoa. Putting the state from the closure in the url is not the same as putting the closure in the url.
Earlier quoted context omitted.
Except it doesn't appear to work robustly, which makes it poor design. "Automating boring and time consuming stuff," is all well and good if it actually produces a functional system, but that concern is secondary to robustness.
It'd work robustly enough if the links didn't expire, and if we believe other posts on this page, the links are expiring due to memory limits on the system. (The other possibility is a timeout, I guess, which is easily fixed.) If it's running out of memory to store the closures it would run out of memory to store the interaction state. In other words, there's a problem here, but it's not the programming model that pg…
Furthermore, the technique of holding important state authoritatively in memory like this is not a good web-development practice for various reasons. Doubly so if its state data which can be round-tripped. Links should not break when the web server or cache (I'm not sure which one it is) runs low on memory. So yes, there is a problem with the programming model that pg chose.
Earlier quoted context omitted.
You don't want to execute code from URLs. (Yes, you can use cryptography to "sign" URLs you create. Don't try that at home unless you know the difference between MACs and hashes, and how to avoid timing attacks.)
Whoa, whoa. Putting the state from the closure in the url is not the same as putting the closure in the url.
Earlier quoted context omitted.
Except it doesn't appear to work robustly, which makes it poor design. "Automating boring and time consuming stuff," is all well and good if it actually produces a functional system, but that concern is secondary to robustness.
It'd work robustly enough if the links didn't expire, and if we believe other posts on this page, the links are expiring due to memory limits on the system. (The other possibility is a timeout, I guess, which is easily fixed.) If it's running out of memory to store the closures it would run out of memory to store the interaction state. In other words, there's a problem here, but it's not the programming model that pg…
Not necessarily. The way I would approach this is to keep the link cache in memory, but have the links contain the minimal necessary state to reconstruct the link from disk-based storage in the case where the cache is gone. That gives the same excellent median performance without any breakage.
Earlier quoted context omitted.
Whoa, whoa. Putting the state from the closure in the url is not the same as putting the closure in the url.
But you are still likely to want to sign the state so you can tell if it has been corrupted (or deliberately doctored) and reject it if so.