Error generated in cr_GET

[majohansson]

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 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]

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

[sckott]

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]

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]

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

[nicole-brewer]

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 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]

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

[nicole-brewer]

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]

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]

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