From: Ethan A M. <me...@uw...> - 2025-09-10 17:51:33
|
On Wed, Sep 10, 2025 at 5:53 AM Philipp K. Janert via gnuplot-beta < gnu...@li...> wrote: > On Tue, 09 Sep 2025 16:19:58 -0700 > Ethan A Merritt <me...@uw...> wrote: > > > I don't want to be a stickler, but I don't > think changing the docs from "gnuplot.info" > to "www.gnuplot.info" is really the right > way to think about it. [shrug] That's the only part of it I can do myself, and it takes effect immediately. The on-line docs now work again (as seen from here), whereas access was failing yesterday. I hope someone else can arrange a more global long-term fix or at least identify what that fix would be. > The domain/server should be configured to > accept both versions and serve the appropriate > content. That's pretty standard issue, in my > experience. To the limited extent that I understand the error messages that I am seeing, it is not a matter of appropriate content on the server. The query is never getting to the server because some intermediate service provider is failing to deliver it. If I am misunderstanding and there is some configuration thing I can change on the SourceForge end, please let me know. Ethan Best, > > Ph. > > > On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote: > > > > > Ethan can't link to gnuplot.info (note: no leading www.). > > > > Good point. I typed the address into the browser directly because > > Phillipp's reported error message was > > "Firefox does not trust this site because it uses a certificate > > that is not valid for gnuplot.info" > > > > > [...] also fails, with a > > > "DNS resolution error 1001" reported by Cloudflare. > > > Which is strange, as tracert did get an IP, i.e. DNS actually > > > works. > > > > Yes. That's the one I'm seeing. It's an internal error message from > > Cloudflare that I get when I request either > https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxPgQ2mvA$ > or > > > https://urldefense.com/v3/__https://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxK_p5wIQ$ > > > > It does work if I request > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$ > (Chrome or > > Firefox browsers). > > > > The hyperlink references in the pdf version of the user manual use > > the > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$ > form. But the html versions of the manual use > > the gnuplot.info form [no www] everywhere. > > > > That much I can fix. > > I will modify the gnuplot.doc inline html tables and the code in > > doc2web.c to always generate output with the www prefix in the URL. > > > > However it is probably a common "mistake" for users to omit the www > > prefix in web queries since that is no longer as near-universal as it > > once was. For that matter Chrome actively hides the "www." prefix > > when it shows the current site in the bar at the top, so a > > cut-and-paste may fail to capture the full, working, address. > > > > Ethan > > > > > > > > > > > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > Membership management via: > > > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$ > > > > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$ > -- Ethan A Merritt Department of Biochemistry University of Washington, Seattle |