GitHub: A case study in link maintenance and 404 pages (2013)

(chrismorgan.info)

15 points | by roryokane 5 days ago ago

3 comments

  • holman 17 minutes ago ago

    404s were designed for performance, as OP says here, but also to be as simple as possible.

    Part of the difficulty was info leakage; early on there was a lot of concern that a 403 would imply the existence of a repo that the org might otherwise not want known publicly. This was a little trickier in practice, really: early versions of the page took slightly different pathways as it went through auth, so based on the duration of the page to render you could make some assumptions about whether the underlying repo existed or not. It was annoying to sort out, so it wasn't touched very often.

    Certainly a lot could have been done with 404s over the years; they've only gotten worse. I put ultrathin font weights on the error pages move than a decade ago, when they were en vogue, and it kills me every time to see them still there. And, of course, the parallax effect has been removed, so now it's just sort of a dorky Star Wars or Looney Tunes reference without a lot behind it. Weird.

  • tempaccsoz5 2 hours ago ago

    Hilariously, a link given as an example is now effectively broken.

    https://github.com/styleguide/templates/2.0, cited in a comment cited in the article now just redirects to a style guide landing page with no context.

    • lelandfe an hour ago ago

      In their defense, I think that's the right move. There isn't an analogue for that page anymore, so it redirects to the new style guide's landing.

      I think it's rather cool that they've redirects still going for (quick Archive check) 11-year defunct URLs.