ropensci / rcrossref

R client for various CrossRef APIs
https://docs.ropensci.org/rcrossref
Other
165 stars 21 forks source link

Error generated in cr_GET #215

Open majohansson opened 3 years ago

majohansson commented 3 years ago

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 TRUE

Session Info ```r R version 4.1.0 (2021-05-18) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Big Sur 11.4 Matrix products: default LAPACK: /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.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 other attached packages: [1] rcrossref_1.1.0 loaded via a namespace (and not attached): [1] Rcpp_1.0.6 compiler_4.1.0 pillar_1.6.1 later_1.2.0 [5] plyr_1.8.6 tools_4.1.0 digest_0.6.27 jsonlite_1.7.2 [9] lifecycle_1.0.0 tibble_3.1.2 pkgconfig_2.0.3 rlang_0.4.11 [13] shiny_1.6.0 DBI_1.1.1 crul_1.1.0 curl_4.3.1 [17] fastmap_1.1.0 xml2_1.3.2 stringr_1.4.0 dplyr_1.0.6 [21] generics_0.1.0 vctrs_0.3.8 htmlwidgets_1.5.3 DT_0.18 [25] tidyselect_1.1.1 glue_1.4.2 httpcode_0.3.0 R6_2.5.0 [29] fansi_0.5.0 purrr_0.3.4 magrittr_2.0.1 promises_1.2.0.1 [33] ellipsis_0.3.2 htmltools_0.5.1.1 assertthat_0.2.1 mime_0.10 [37] xtable_1.8-4 httpuv_1.6.1 utf8_1.2.1 stringi_1.6.2 [41] miniUI_0.1.1.1 crayon_1.4.1 ```
sckott commented 3 years ago

Thanks for the report @majohansson I'll have a look

sckott commented 3 years ago

I can't reproduce the error right now. Can you try it again?

It was likely a temporary down time on the Crossref side.

befriendabacterium commented 2 years ago

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! Matt

nealhaddaway commented 2 years ago

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,

@nealhaddawayhttps://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 GitHubhttps://github.com/ropensci/rcrossref/issues/215#issuecomment-880572958, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKOBNXGT2OEK7LB4LUMIZOTTX2YAJANCNFSM46O42UTQ.

nicole-brewer commented 2 years ago

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 Info ```R R 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 ```
njahn82 commented 2 years ago

Hi @nicole-brewer can you share the doi you tried?

nicole-brewer commented 2 years ago

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).

majohansson commented 2 years ago

The email fix didn't work for me. I did figure out a work around though. I edited cr_GET() in two places:

# on_error(sprintf("%s (%s): %s - %s", res$status_code, 
#   rcrossref:::err_type(res), rcrossref:::get_route(res), rcrossref:::get_err(res)), call. = FALSE)
on_error(sprintf("%s (%s): %s", res$status_code, 
    rcrossref:::err_type(res), rcrossref:::get_route(res)), call. = FALSE)

...

#stopifnot(res$response_headers$`content-type` == "application/json;charset=UTF-8")
stopifnot(res$response_headers$`content-type` == "application/json")

The second one is the more critical and I am not sure why I am getting a different content-type than expected, but this fixed it. I think a string match would probably make this more robust to either version. First one was causing problems with some 404 errors that I couldn't quickly sort it.

sckott commented 2 years ago

I am not sure why I am getting a different content-type than expected,

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 - remotes::install_github("ropensci/rcrossref")