-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error generated in cr_GET #215
Comments
Thanks for the report @majohansson I'll have a look |
I can't reproduce the error right now. Can you try it again? It was likely a temporary down time on the Crossref side. |
Hi there, @nealhaddaway and I just tried running some old code (https://github.com/befriendabacterium/doifetchR) and got exactly the same error. CrossRef doesn't seem to be down right now. Any ideas what's causing this please? Thanks! |
I fixed the issue by adding my email to the R environment as suggested in the Documentation:
To pass your email address to Crossref via this client, simply store it as environment variable in .Renviron like this:
1. Open file: file.edit("~/.Renviron")
2. Add email address to be shared with Crossref crossref_email = ***@***.***
3. Save the file and restart your R session
…________________________________
From: Matt Lloyd Jones ***@***.***>
Sent: 15 July 2021 10:12
To: ropensci/rcrossref ***@***.***>
Cc: nealhaddaway ***@***.***>; Mention ***@***.***>
Subject: Re: [ropensci/rcrossref] Error generated in cr_GET (#215)
Hi there,
@nealhaddaway<https://github.com/nealhaddaway> and I just tried running some old code (https://github.com/befriendabacterium/doifetchR) and got exactly the same error. CrossRef doesn't seem to be down right now. Any ideas what's causing this please?
Thanks!
Matt
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#215 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKOBNXGT2OEK7LB4LUMIZOTTX2YAJANCNFSM46O42UTQ>.
|
I also have this issue. Tried the suggestion to create an R environment variable for the crossref email, but that didn't fix the problem. Any doi or format gives me this same error. > pubs <- rcrossref::cr_cn(dois = my_doi, format = "bibtex")
Error in cr_GET(endpoint = sprintf("works/%s/agency", x), args = list(), :
res$response_headers$`content-type` == "application/json;charset=UTF-8" is not TRUE Session InfoR version 4.1.1 (2021-08-10)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS High Sierra 10.13.6
Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /usr/local/Caskroom/miniconda/base/envs/R/lib/libopenblasp-r0.3.18.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] rstudioapi_0.13 knitr_1.35 magrittr_2.0.1 usethis_2.1.3 tidyselect_1.1.1 R6_2.5.1
[7] rlang_0.4.12 fastmap_1.1.0 fansi_0.5.0 dplyr_1.0.7 tools_4.1.1 xfun_0.27
[13] utf8_1.2.2 cli_3.1.0 DBI_1.1.1 htmltools_0.5.2 ellipsis_0.3.2 yaml_2.2.1
[19] digest_0.6.29 assertthat_0.2.1 tibble_3.1.6 lifecycle_1.0.1 crayon_1.4.2 purrr_0.3.4
[25] fs_1.5.1 vctrs_0.3.8 glue_1.5.1 evaluate_0.14 rmarkdown_2.11 compiler_4.1.1
[31] pillar_1.6.4 generics_0.1.1 vitae_0.5.1 pkgconfig_2.0.3 |
Hi @nicole-brewer can you share the doi you tried? |
Solved. The problem was that I was using the DOI (10.1007/s41781-021-00069-9), instead of the full url (https://doi.org/10.1007/s41781-021-00069-9). |
The email fix didn't work for me. I did figure out a work around though. I edited cr_GET() in two places:
...
The second one is the more critical and I am not sure why I am getting a different |
the problem is on Crossref's side. they should not be changing content type on an error, but apparently they do. the content type on error is probably html, but it's not always that, just sometimes. the reason the content type check is there is that we want to avoid trying to parse the wrong content type of data, which will fail. the ultimate fix would be to have crossref fix how they return errors, but that's unlikely to happen. the development version of rcrossref has that stopifnot line commented out - |
I'm getting an error with the cr_works() example (see below). Using a windows machine on the same network, same R version, I get no error.
cr_works(query="NSF")
Error in cr_GET(endpoint = path, args, todf = FALSE, ...) :
res$response_headers$
content-type
== "application/json;charset=UTF-8" is not TRUESession Info
The text was updated successfully, but these errors were encountered: