Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Dirk Eddelbuettel]

Thank you all -- expecially Aron and Ivan for the deep dive on the underlying
aspect of the hosting of that web property.  And of course to Uwe for
approving the package manually.

For my taste, life is too short for all this. So users be damned, and I have
now removed the badge.  At the end of the day it is better for Uwe et al (and
of course our side) to have these things autoprocess. If this kind of stuff
is in the way, I will just remove it as maintainer.

Thanks again to all.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Ivan Krylov]

On Thu, 30 Nov 2023 10:49:36 -0600
Dirk Eddelbuettel  wrote:

>   Found the following (possibly) invalid URLs:
> URL: https://anaconda.org/conda-forge/r-tiledb
>   From: README.md
>   Status: 400
>   Message: Bad Request

The problem is that https://anaconda.org/conda-forge/PACKAGE fails to
answer to HEAD requests and only answers to GET requests. HEAD differs
from GET in that there is no need to send the actual content of the page
in response to the request; it is enough to say "200 OK" (and pass the
check) or, as it happens here, "400 Bad Request".

It may help to ask ContinuumIO to support HEAD requests by filing a bug
report for the Anaconda.org website at
. It may be worth
referencing RFC 9110, section 9.3.2
, in
particular:

>> The HEAD method is identical to GET except that the server MUST NOT
>> send content in the response.

>> The server SHOULD send the same header fields in response to a HEAD
>> request as it would have sent if the request method had been GET.

Arguably, the spirit of the standard is being violated here (if not the
letter, which only mentions headers).

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Uwe Ligges]

On 30.11.2023 18:28, Aron Atkins wrote:

On Thu, Nov 30, 2023 at 11:49 AM Dirk Eddelbuettel  wrote:



And *of course* the same URL resolves fine for me in the browser without
any
apparent redirect.  Bit of a web newb here but is there anything I can do
short of deleteing the badge?



The badge you're referencing is hosted by a cloudflare CDN, which uses
"magic" to return error responses to non-humans.

You can see this behavior by running curl against the URL:

curl -I https://anaconda.org/conda-forge/r-tiledb
HTTP/2 400
server: cloudflare
...

I have seen this behavior for other resources, but generally have
experienced 403 responses.

This urlchecker issue discusses what I had seen:
https://github.com/r-lib/urlchecker/issues/26

I do not have guidance other than to either remove the URL or add a note
stating that the 400 errors are only presented to robots. Perhaps CRAN
occasionally adjusts its User-Agent to avoid some of these challenges? Not
sure.

Aron


This (status 400) underlies manual inspection and we let this pass.

Best,
Uwe Ligges

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Aron Atkins]

On Thu, Nov 30, 2023 at 11:49 AM Dirk Eddelbuettel  wrote:

>
> And *of course* the same URL resolves fine for me in the browser without
> any
> apparent redirect.  Bit of a web newb here but is there anything I can do
> short of deleteing the badge?


The badge you're referencing is hosted by a cloudflare CDN, which uses
"magic" to return error responses to non-humans.

You can see this behavior by running curl against the URL:

curl -I https://anaconda.org/conda-forge/r-tiledb
HTTP/2 400
server: cloudflare
...

I have seen this behavior for other resources, but generally have
experienced 403 responses.

This urlchecker issue discusses what I had seen:
https://github.com/r-lib/urlchecker/issues/26

I do not have guidance other than to either remove the URL or add a note
stating that the 400 errors are only presented to robots. Perhaps CRAN
occasionally adjusts its User-Agent to avoid some of these challenges? Not
sure.

Aron
-- 
email: aron.atk...@gmail.com
home: http://gweep.net/~aron/

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel