[R-pkg-devel] Logical Inconsistency of check regarding URL?
hugo@gruso@+R m@iii@g oii @orm@iesup@org
hugo@gruso@+R m@iii@g oii @orm@iesup@org
Tue Nov 29 10:17:01 CET 2022
Dear Michael,
I second Ivan's suggestion to use a custom domain on your GitHub Pages
website and I also want to add that this solves your certificate issue
as a nice side-effect.
GitHub will automatically create a certificate for you, for free, via
Let's Encrypt:
https://github.blog/2018-05-01-github-pages-custom-domains-https/
Best,
Hugo
On 29/11/2022 08:55, Ivan Krylov wrote:
> Dear Michael,
>
> On Tue, 29 Nov 2022 08:19:40 +0100
> "Dr. habil. Michael Thrun" <m.thrun using gmx.net> wrote:
>
>> URL: https://www.deepbionics.org (moved to
>> https://mthrun.github.io/index)
>> From: DESCRIPTION
>> Status: 301
>> Message: Moved Permanently
>
>> Please change http --> https, add trailing slashes, or follow moved
>> content as appropriate. "
>
> The "HTTPS and trailing slashes" part is a red herring. The idea is to
> only have URLs in your package that return HTTP code 200.
> The website https://www.deepbionics.org redirects to
> https://mthrun.github.io/index, which is, strictly speaking, against
> the letter of the rules [1]. Websites that redirect from http://... to
> https://... and from .../website/path to .../website/path/ (and the
> other way around) are a common cause of such redirects, which is why Uwe
> mentioned it (I think), but this isn't the reason for the redirection at
> https://www.deepbionics.org.
>
> I think you could make the argument that https://www.deepbionics.org is
> the canonical URL for the website and the way it _currently_ works (by
> returning a 301 redirect to https://mthrun.github.io/index) is an
> implementation detail that should be ignored, but I don't know whether
> CRAN reviewers would agree. I think it should be possible to set up
> your domain and GitHub Pages to serve mthrun.github.io at the address
> www.deepbionics.org without a redirection [2], but I've never tried it
> myself.
>
>> First, do we not communicate with CRAN anymore through the submission
>> procedure of the package? If not, which is the correct line of
>> communication in such a case?
>
> There was a case once when the reviewer was mistaken (they were in the
> process of heroically clearing out the "newbies" queue that almost
> reached 80 packages, aged 10 days and more, all by themselves, so a
> certain amount of fatigue was to be expected) and I was able to argue
> my way out of a rejection by replying to the reviewer. I think that the
> way to go is to either submit a package with requested changes and an
> incremented version or to reply-to-all and argue the case for the
> package as it is now.
>
>> Third, why can I have a CRAN package "DataVisualizations" with this
>> URL online, another one named "GeneralizedUmatrix" uploaded the same
>> day with the same URL, which both are OK, but the URL in
>> "DatabionicSwarm" is not?
>
> Has anything changed recently regarding the way your domain is set up?
> It really is strange that the check passed for one of the packages but
> not the other.
>
>> Fifth, why do we need https/TLS/SSL?
>
> I think you're right (see also: depriving an existing website of its
> certificate as a means of censorship), but the browser makers may end
> up destroying TLS-less workflow for us in a few years. Thankfully, it's
> not a requirement of CRAN to have only HTTPS links. I probably
> shouldn't continue this topic because the question of "how the Web
> should function" tends to result in pointlessly heated debates.
>
More information about the R-package-devel
mailing list