
Please fix: Unknown or expired link. - kijin
I&#x27;m pretty sure that the HN community likes to read thoughtful, thoroughly researched comments that are somewhat longer than one-liners. But whenever I take more than a few minutes to write a comment, I am greeted with the following error message as soon as I hit &quot;Submit&quot;:<p><pre><code>    Unknown or expired link.
</code></pre>
Fortunately, I can usually hit the Back button, refresh the page, and resubmit my comment without losing the contents of the textarea. Anyway, I try to be extra careful and copy the comment to the clipboard before I hit &quot;Submit&quot; if I feel like it&#x27;s been more than a few minutes since I started writing.<p>But this should not be necessary in the first place.<p>Please increase the timeout on your CSRF tokens (or whatever it is that triggers the error message above) to something more user-friendly. I would suggest a sensible default of 86400 seconds.<p>Thanks.
======
dang
I'll try to respond to everything in one comment.

kogir and I talked recently about getting rid of "unknown or expired link".
It's on our list. There are a lot of things on the list; we don't know yet
when we'll get to it.

There's work ongoing to make HN more usable on mobile. This will likely roll
out sooner than the above. We intend to roll it out incrementally, starting
with the front page. We'll give people lots of notice so anyone running
scrapers that are affected (like me!) will have time to change.

The look and feel of HN is unlikely to change much. We can argue about that
one till the cows come home. I'm tempted to—my opinions are as strong as many
of yours—but that doesn't seem like the best idea right now.

Feature requests should go to
[https://news.ycombinator.com/item?id=363](https://news.ycombinator.com/item?id=363).
Software bugs should go to
[https://github.com/HackerNews/HN/issues](https://github.com/HackerNews/HN/issues).
That would have been the appropriate destination for the OP, and indeed this
issue has been posted about there.

Threads like the current one get lots of upvotes and comments, but they've
never been on topic for HN. I'm going to bury this one now.

~~~
krapp
How is it not on topic for HN?

It would be on topic to discuss the implementation of any other site.

~~~
dang
What's on topic for HN, as the guidelines say, are stories that gratify
intellectual curiosity. Meta posts gratify several things, but that is not one
of them. They generate masses of comments like fast-growing weeds, because
we're all full of opinions about HN, but the discussions never go very deep,
or really anywhere. This has been the case for many years—pretty much since
the beginning of the site—and so has the policy on it.

~~~
krapp
You don't think a community of programmers and hackers and UX nerds would or
should be intellectually curious about why a forum written in a Lisp dialect
works and why it doesn't, and how it solves, or doesn't solve, various
problems?

I can understand why it's annoying for the staff to have to encounter these
threads so often - it's annoying for users to keep running into dead links.
But I don't think it's entirely true that this topic has no value to the
community at large. Having opinions and discussing things is kind of what
forums are supposed to be about.

~~~
SamReidHughes
But look at the actual discussion here. It's mediocre.

~~~
krapp
I guess I can't argue with that, even though I personally find the subject
more interesting than politics or talk about sexism in tech or bitcoin...
everyone's mileage varies.

Though I would disagree with the premise that meta-discussion, necessarily, is
a bad thing. At the very least given the nature of the site and its userbase,
it's going to be inevitable.

------
chrismorgan
This has bearing on my _absolutely favourite_ part of the Web Content
Accessibility Guidelines (WCAG) 2.0:

Section 2.2.1, Timing Adjustable ([http://www.w3.org/TR/WCAG20/#time-limits-
required-behaviors](http://www.w3.org/TR/WCAG20/#time-limits-required-
behaviors)):

\----

2.2.1 Timing Adjustable: For each time limit that is set by the content, at
least one of the following is true: (Level A)

\- Turn off: The user is allowed to turn off the time limit before
encountering it; or

\- Adjust: The user is allowed to adjust the time limit before encountering it
over a wide range that is at least ten times the length of the default
setting; or

\- Extend: The user is warned before time expires and given at least 20
seconds to extend the time limit with a simple action (for example, "press the
space bar"), and the user is allowed to extend the time limit at least ten
times; or

\- Real-time Exception: The time limit is a required part of a real-time event
(for example, an auction), and no alternative to the time limit is possible;
or

\- Essential Exception: The time limit is essential and extending it would
invalidate the activity; or

\- 20 Hour Exception: The time limit is longer than 20 hours.

 _Note:_ This success criterion helps ensure that users can complete tasks
without unexpected changes in content or context that are a result of a time
limit. This success criterion should be considered in conjunction with Success
Criterion 3.2.1, which puts limits on changes of content or context as a
result of user action.

\----

Yea, verily! HN isn’t even Level A (the most basic level that "everyone"
should comply with) compliant. _Through this, HN fails Accessibility 101._
(Its text colour choices are also often dubious as far as contrast goes—that’s
covered in WCAG 2.0 as well, of course.)

I simply don’t care about the technical reasons. The choice of coroutines to
back all of these things has broken the basic accessibility of all the
content.

~~~
zura
> The choice of coroutines to back all of these things has broken the basic
> accessibility of all the content.

Exactly. This is actually a good example of More is Less.

------
IgorPartola
Also, can someone _please_ make the site render with a larger font on mobile?
I am spending a fortune on new glasses and contact lenses, as well as monocles
and loupes just to read HN when not on my computer. So many people on here
have asked for this over the years. Perhaps this is a subtle attempt by the YC
to make sure all the people in our industry have to use eyewear so we can
recognize each other at the secret meetings. Maybe this has something to do
with Gunnar Optiks marketing eyewear for geeks? Maybe YC is about to fund an
optometrist practice. Or maybe someone here knows that Apple is about to
release a 20 inch iPad?

Please, for the love of everything that is good and pure and true, make the
font larger!

Sincerely, Blind among blind

Edit: please don't suggest one of the other HN wrappers. I know they exist. I
don't want to hand over my HN password to them. My HN identity is important to
me, so unless I can run my own wrapper on my own servers I don't want it.

Edit edit: I believe if HN mods/operators announced a contest for best mobile
design they'd get a ton of submissions. Sadly I am not a designer and could
not participate, but I am sure the amount of submissions would be huge.

~~~
loup-vaillant
Can't you control the minimum font size on your mobile browser or something?

~~~
IgorPartola
I believe on iOS you can increase the font size for the entire UI, not just
the browser. Not something I would want to do. No idea about Android.

------
jamesmoroni
This happens with the next page button as well if I've been on the page for
more than 3 minutes or so.

~~~
Quai
I see this almost every day. I have always assumed that Hacker News is too
cool to fix/support navigation after the frontpage (or any other page) has
changed.

~~~
judk
It's not "cool", it's that the implementation is a quick hack, not intended to
be a quality product. It just needs to be good enough to make users grudgingly
return and see the PR for YC startups.

------
pfg
See [1] on why this is happening. Relevant part:

>Internally, the web server associates a token called the fnid with each
instance of a link or form, and records the continuation function for each
token. Periodically, old fnids are deleted.

[1]:
[http://arclanguage.github.io/ref/srv.html](http://arclanguage.github.io/ref/srv.html)

~~~
kijin
Thanks for the reference.

Any idea where the fnids are stored and how they are garbage-collected? Could
it be that they're just dumped into a memcached instance and older fnids get
pushed out whenever the memory limit is reached?

~~~
wahnfrieden
It's not the fnid that gets garbage collected, it's the coroutine itself.

------
grey-area
I have a modest proposal for addressing the terrible dearth of fnids on this
site. Since fnids are in such high demand, and yet are expensive to keep in
memory, one small change might free up lots of them - _remove the use of fnids
for more pages and use a static url instead_

so the more link on:

[https://news.ycombinator.com/news](https://news.ycombinator.com/news)

would point to:

[https://news.ycombinator.com/news/2](https://news.ycombinator.com/news/2)

and so on.... This would free up many fnids for use elsewhere, and also make
the secondary list pages more easily cacheable and reduce load on the server.

The same could be done for other lists which currently use fnids without any
appreciable change in the user experience or probably much change in the
server code.

------
sergiotapia
Public Service Announcement:

If you're on Chrome use HackerNews Enhancement Suite.

[https://chrome.google.com/webstore/detail/hacker-news-
enhanc...](https://chrome.google.com/webstore/detail/hacker-news-
enhancement-s/bappiabcodbpphnojdiaddhnilfnjmpm)

No more ass-ugly hackernews font choices and colors.

~~~
sk5t
Neat! Worth it for the option to collapse threads alone. Recently some
_extraordinarily_ lengthy, tedious threads have dominated the discussion on
otherwise-interesting topics, and simply finding the end of the dreck was a
problem.

------
phamilton
One positive side effect of the architecture is proper isolation in
pagination. When I fetch Page 1, the link to Page 2 will always return the
same set, regardless of timing (up until it expires). You will never see the
last entry on one page show up as the first entry on the next page.

------
midnitewarrior
Ya, for a community that is supposed to value great design and technical
acumen, this site looks like somebody's pet project that was abandoned.

~~~
danford
I don't really mind the design. I have a feeling they purposely keep the site
design simple and, what some might consider "unappealing" to the average user.
Helps weed out the normies.

~~~
judk
It also weeds out the adults who think about what they read and don't have
child eyes.

~~~
nitrogen
You can always zoom in or enable high DPI mode if your browser supports it

~~~
6cxs2hd6
Or one can always make a mother*ucking web site [^1], which works perfectly in
every browser. Zero issues with font size, layout and scrolling. Just-works.

[1]: [http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

------
BrandonMarc
So ... is this a bug or a feature?

Is the internal activity causing this unpopular behavior _supposed_ to do
this, in the first place? If the site is indeed behaving exactly as its
designers want it to, then that's a rather separate debate as opposed to
simply ways and means.

I'm not saying I agree with the behavior; I'm just trying to see what should
be debated to start with.

~~~
Raphael
Yes, the order changes over time, so the second page will often contain items
from the old first page.

------
jmount
I agree with you: HN time-outs and failures (which also occur on reading) are
an unnecessary pain. This is one reason you should never write into a web text
box (a rule I also fail to adhere to). But really even "modern application
grade" web stuff is so flakey if you value your text you write it in a local
editor and then copy/paste later.

~~~
BrandonMarc
With this rule in mind, I wonder if a textures / notes area would be a good
feature to include in the web browser itself (including mobile browsers) ...

------
dfc

      > I'm pretty sure that the HN community likes to read thoughtful, thoroughly
      > researched comments that are somewhat longer than one-liners.
    

Could not agree more and this is a great side effect of the time out. It gives
the commenter yet another reason to compose their comment in a real editor.
Personally I find the comment text box is too small to do a decent job of
assessing and editing my comment. A real editor also makes it easy to format
the above blockquote[^1] or to insert[^2] logical and consistent
footnotes.[^3]

[^1]: [http://www.nicemice.net/par/](http://www.nicemice.net/par/)

[^2]: [http://jblevins.org/projects/markdown-
mode/](http://jblevins.org/projects/markdown-mode/)

[^3]: I just wish markdown-mode would renumber the footnotes if I go back and
insert a new footnote. As it is I have to pipe the output through pandoc

------
brudgers
It's not a priority for HN development. See Graham's 2009 essay for an
explanation of what matters:

[http://paulgraham.com/hackernews.html](http://paulgraham.com/hackernews.html)

------
Kiro
Can someone explain why this expiration thing is happening like I'm 5? Even
the most basic PHP tutorial app doesn't have this problem so I don't
understand people saying it's inevitable.

------
cordite
Yeah, it's really annoying to have to edit the URL on mobile when this
happens..

------
throw_away12847
I really do believe that HN is poorly designed for end users. The UI is not
forward with intent, or pleasurable to use. It's been literally years and the
expired link issue hasn't been addressed. ---No, I'll stop you right there.
It's been acknowledged as an implementation bug, but not addressed. PG's lack
of user empathy and stubbornness make HN worse.

The only reason people come here is the content.

~~~
btilly
_The only reason people come here is the content._

I consider this a good thing. It attracts the right kind of people.

~~~
throw_away12847
Are you insinuating that the key to dissuading the _wrong_ kind of people is
to make Hacker News difficult to use? The notion that good users will "power
through" a bad design is dubious at best.

I hope that you're not involved in product design. This thought process is not
good for anyone.

~~~
btilly
I make no apologies for my opinion, however much you dislike it.

I've maintained for years that the key to a high quality online forum is for
it to be limited in some way. It can be limited by bugs. Limited by nobody
advertising that it exists. Limited by having a very focused topic of
discussion. I'm willing to believe that it can be limited by moderation, but I
self-select out of those forums so don't know.

But without some sort of limiting you get what happened to Usenet, Slashdot,
kuro5hin, the main page of Reddit, and so on. Which is that they became the
place that everyone knew that they should go. And then the noise went up
faster than the signal, resulting in a poor signal to noise ratio. And then
the best people found new forums to go to, and slowly disappeared.

Of course if you make the limiting TOO effective, eventually nobody will be
left. There is a balance to be had.

And this only applies to high quality content of the kind that I want to
engage with. Which is admittedly not to everyone's taste. It is not a way to
make something popular.

------
jellicle
For any new readers: this is a "bug by design", it has been extensively
complained about in the past, and it's marked "will not fix, stop complaining"
by management.

This has been a public service announcement.

~~~
akkartik
Not true. It's an open bug. It's just really hard to fix.

[https://github.com/HackerNews/HN/issues/11](https://github.com/HackerNews/HN/issues/11)

~~~
falcolas
With all due respect, if a framework makes storing sessions for more than 30
minutes "hard", there's something fundamentally wrong with the framework. This
has been a solved problem for longer than I have worked in the industry.

~~~
akkartik
Yes, it's been frustrating to me as well:
[https://news.ycombinator.com/item?id=5032739](https://news.ycombinator.com/item?id=5032739).
Just an unfortunate consequence of starting out as a prototype.

------
vannevar
This 'bug' has been around so long that at this point I suspect that it's
really just a long-running troll.

------
lutusp
There's a reason things are set up as they are:

* Although HTTP connections are normally stateless, HN has a login system for account holders, which means there's a state, a connection, associated with each logged-in user.

* Because of the state information associated with logins, A Web server has a limited number of login connections it can handle.

* To serve the maximum number of visitors, a server needs to recycle connections that are no longer in use.

* There's no reliable heartbeat method between browser and server that a server can use to determine whether a given connection is still in use. Also, heartbeats would represent an extra traffic load on the server. And now that tabs have become popular, there's no way to be sure that a heartbeat response isn't from an unused, forgotten tab among dozens.

* Therefore, after a connection has not seen packet requests for a set time interval, the server expires the connection to make it available to other visitors.

* The shorter the timeout, the more connections the server can handle.

> I would suggest a sensible default of 86400 seconds.

Let's say the server can handle 2048 simultaneous login sessions (I don't know
the actual number). According to your suggestion, after the first 2048
visitors log in, the server would refuse to accept any new logins for 24
hours. This isn't realistic.

Here's how I handle the problem -- if I decide a reply is going to take more
than a few seconds, I transfer my reply to a text editor and let the
connection expire. When my long-winded reply is ready, I refresh the original
page, paste my reply in, and click "Add Comment".

I hope this helps.

~~~
nwh
I don't think this is what is going on here, it makes no sense for it to
operate like this. To demonstrate this is not the case, I just momentarily
unplugged my NIC and then submitted this comment. The connection was
definitely dropped and re-associated, but my comment passed perfectly fine.
This is more likely a very short cache time on CSRF tokens rather than
anything to do with associated sockets.

~~~
brudgers
The architectural model your comment and the initial post assumes to underlay
the behavior is incorrect.

The reason for 'Unknown or Expired Link' is that HN runs on a webserver that
uses continuations to maintain state. The continuations are stored in a table
and based on load individual table entries get flushed to make room for new
entries as needed. The message is actually always the result of an unknown
link because the hash is no longer in the table.

Your experiment worked because the relevant continuation [state reference] was
available after disconnect e.g. the 'route' so to speak was still valid.

Now obviously one might wonder why HN works this way. The reason is that the
HN codebase came about as a way of field testing Arc [Graham's 100 year
language]. Until rather recently, HN ran on a single server. It still uses
relatively few lines of code.

~~~
acdha
> Now obviously one might wonder why HN works this way. The reason is that the
> HN codebase came about as a way of field testing Arc [Graham's 100 year
> language].

This is really the key point: continuations are the wrong way to write this
kind of application. It's significantly more work and there's no benefit from
doing so _but_ it allowed someone to test a pet idea and, having done so,
fixing it would mean admitting that doing something because it's cool isn't
good engineering.

~~~
brudgers
The kind of application is specifically Hacker News, not a generic website or
webserver. See the essay linked here for what kind of application this is:

[https://news.ycombinator.com/item?id=7651525](https://news.ycombinator.com/item?id=7651525)

~~~
acdha
Continuations are a questionable fit for web applications in general, however.
HTTP is stateless and it requires a lot of extra work to build an abstraction
which pretends otherwise. I prefer to embrace that from the beginning so the
entire design matches the nature of the medium.

~~~
brudgers
The explanation is mine. It wasn't an argument.

The application and implementation decisions are YC's. The essay explains
their rationales.

