Re: [Bug-ed] Project page HTML validation link broken
Hi Bob, Thanks for your efforts. :-) Bob Proulx wrote: I have tried to remove the "http:" part (from another page), and it doesn't work on a not very recent version of Seamonkey. I think I'll change the "http:" to "https:" instead. I like it. Using "https:" is certainly always safe. Sadly I have discovered that even if "https:" is always safe, it not always works on (not so) old browsers: "As of May 07, 2017 the Fossies server fossies.org is now only be accessible by HTTPS using the modern TLSv1.2 protocol to make sure the exchanged information and data are always protected. A hint: If you use for some strange reasons an old client (for e.g. lower than Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8) you can access the Fossies data still by the HTTP protocol by using instead of the native host name fossies.org the alternate name fresh-center.net and URLs like http://fresh‑center.net/...; Given that the "valid html" button is not a required feature of the ed page, and the problems it has already caused, I have finally removed it. Sorry for the inconveniences. Best regards, Antonio. ___ bug-ed mailing list bug-ed@gnu.org https://lists.gnu.org/mailman/listinfo/bug-ed
Re: [Bug-ed] Project page HTML validation link broken
A while back was this discussion: Antonio Diaz Diaz wrote: > Thomas Cort wrote: > > At the bottom of the project page[1] there is a link "Valid HTML 4.01 > > Strict"[2]. It passes uri=referer to the validation service, but gnu.org > > forces HTTPS and browsers generally do not set the Referer header when > > leaving an HTTPS site, so the link almost never works unless you're on an > > older or insecure browser. > > Thanks for reporting this. > > It works for me[1], and uri=referer is the way recommended by the W3C in the > link below. Some long standing legacy behavior has been caught up in the tangle as things are (slowly) changing. Due to the hostile nature of the Internet it is necessary to add more protections. Among those being more https everywhere. > Moreover, in the W3C error page for "No Referer header found!" it states > that "This is not an error in the referring page!". I think (personal opinion) that the above probably reflected that author's viewpoint that browsers should set the referrer header even when leaving an https page for a http link. But that is what the popular browsers do. Not much us unwashed masses can do about it. > I'm not sure if I like this https thing, and I do not feel like hardcoding > the url, so I'll probably remove the "Valid HTML" link. The link suggested by the validator page includes the "http:" part. But times have changed. If coming from an https page that needs to be an https link in order to have browsers set the referrer. If the page is always going to be https then that link can be changed to an https link and everything will work properly. Because the www.gnu.org pages now redirect to https if coming to an http URL we can now assume that the link should always be https too. This following should be safe. https://validator.w3.org/check?uri=referer;> http://www.w3.org/Icons/valid-xhtml10; alt="Valid XHTML 1.0 Strict" height="31" width="88" /> For general use on either http or https pages however a (new in the grand scheme of things) URL syntax is allowed. One can leave off the protocol entirely. If it is not present then the protocal of the link will be the same as the current page. (The "//" part denotes a prefix to a hostname as it has always done. If it is without a leading double slash then the path refers to the current host.) http://www.w3.org/Icons/valid-xhtml10; alt="Valid XHTML 1.0 Strict" height="31" width="88" /> The above works for either http or https pages. This is what I use on my pages. I recommend removing the "http:" part from the current page leaving it looking like the above. Hope this helps! Bob ___ bug-ed mailing list bug-ed@gnu.org https://lists.gnu.org/mailman/listinfo/bug-ed
