CRAN URL checks

The CRAN submission checks run by R CMD check --as-cran check the availability of URLs in files including DESCRIPTION, CITATION, NEWS.Rd, NEWS.md, README.md, and the .Rd help pages and HTML files in inst/doc. These notes explain the checks.

They are only done if the build of R in use supports a suitably recent version of libcurl: most should.

• \url markup should only be used for always-active URLs. Examples of the use of e.g. localhost should use \samp markup.
• The checks done are equivalent to using curl -I -L on the command line (where curl is available). They may give different results from accessing the URL in your browser. Possible reasons include:
  • Some websites do not allow ‘HEAD’ requests. That should be reported with a 405 status value, and such sites are not reported in the checks. But some are mis-configured, notably ‘http://www.sciencedirect.com’ (which is special-cased in the checks).
  • It is possible that a site relies on cookies you have saved in your browser or is insecure and you have saved an exception. Try a vanilla browser session, another browser or even another machine.
  • If there are issues with verifying the identity of the site, the checks will report if the site is accessible without verification. The checks use the root certificates which libcurl was compiled to use: on most systems these are from the OS (by default on Windows those shipped with the libcurl binaries are used). Browsers may use the OS versions, or may use their own copies which can explain discrepancies.
  • HTTP sites reporting status codes 403 and 503 may work in a browser, although most do not. This has even been seen for status code 404.

  If you find one of the exceptions, explain your findings in the submission.

• There may be sites which are available to some users but not to all, so may work for you but not the CRAN maintainers. Such sites are best avoided, but may be used in a .Rd file provided this is explained in the file and in the submission.
• A surprisingly large number of websites use redirection and the issues may apply to a site redirected to. You can see the redirection history using curlGetHeaders("http://www.mywebsite.org/"). Where redirection is permanent you should use the redirected URL (see RFC 7231).

  One common issue is the redirection of http:// URLs to https:// URLs, or even vice versa.

• The timeout allowed for making a connection to a site is 60 seconds. This is normally more than adequate and avoids long delays for sites which will never respond. But sometimes the DNS lookup for a rarely-used site on a slow network takes longer than that, so if a site is not resolved it is worth re-trying 15 minutes later.