emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3


From: Ihor Radchenko
Subject: Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ <censored>)]
Date: Mon, 04 Jul 2022 20:58:01 +0800

Tim Cross <theophilusx@gmail.com> writes:

>> This sounds like a good idea.
>> I am not sure if it is feasible, but the 404 page could also provide
>> suggestions based on similar existing links. I have something like
>> https://list.orgmode.org/orgmode/83tu89b7pr.fsf@gnu.org/ in mind.
>
> Sorry, I don't understand the relevance of that link (it seems to be to
> a discussion about GC size?).

The link I provided is pointing to a thread, which is not in Org ML.
Yet, list.orgmode.org is able to detect messages in other mailing lists
:)

For me, the page in the link looks like:

Message-ID: <83tu89b7pr.fsf@gnu.org>
found in another inbox:

https://yhetil.org/emacs-devel/83tu89b7pr.fsf@gnu.org/

Perhaps try an external site:

https://marc.info/?i=83tu89b7pr.fsf@gnu.org
https://www.mail-archive.com/search?l=mid&q=83tu89b7pr.fsf@gnu.org
nntp://news.gmane.io/83tu89b7pr.fsf@gnu.org
https://lists.debian.org/msgid-search/83tu89b7pr.fsf@gnu.org
https://docs.FreeBSD.org/cgi/mid.cgi?db=mid&id=83tu89b7pr.fsf@gnu.org
https://www.w3.org/mid/83tu89b7pr.fsf@gnu.org
http://www.postgresql.org/message-id/83tu89b7pr.fsf@gnu.org
https://lists.debconf.org/cgi-lurker/keyword.cgi?doc-url=/lurker&format=en.html&query=id:83tu89b7pr.fsf@gnu.org

> Yes, you should be able to use JS to examine the URL which failed and
> transform it by making the first character of each word in the url
> filename upper case. Essentially do what was proposed with the rewrite
> rules, but which wouldn't have the same performance hit as it would only
> be triggered when incorrect URLs were entered and wold run in the browser.
>
> The only downside is it wouldn't work with non JS based browsers (like
> eww). If the server had support for server side scripting (perl, ruby,
> etc) it could be done so that it would work with all browsers by doing
> the rendering server side.

If JS is the only option it is still better to have it and fall back to
more generic page if JS is not supported. Of course, given that the JS
code is not going to be too complex and not going to require too much
maintenance.

Best,
Ihor




reply via email to

[Prev in Thread] Current Thread [Next in Thread]