Add tests and make sure content type matching in request bodies is working

[sckott]

still not sure if it's working or not

[EHJ-52n]

I am using the following set-up:

> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/lib/openblas-base/libblas.so.3
LAPACK: /usr/lib/libopenblasp-r0.2.19.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=C              LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] sos4R_0.4.0.9000 stringr_1.3.1    httr_1.4.0       webmockr_0.3.0   testthat_2.0.1   sf_0.7-2        

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.0        pillar_1.3.1      compiler_3.5.2    class_7.3-14      prettyunits_1.0.2 remotes_2.0.2     tools_3.5.2       digest_0.6.18     pkgbuild_1.0.2    pkgload_1.0.2     jsonlite_1.6      memoise_1.1.0    
[13] tibble_2.0.1      lattice_0.20-38   pkgconfig_2.0.2   rlang_0.3.1       DBI_1.0.0         cli_1.0.1         rstudioapi_0.9.0  curl_3.3          rgdal_1.3-6       yaml_2.2.0        e1071_1.7-0.1     xml2_1.2.0       
[25] withr_2.1.2       fauxpas_0.2.0     desc_1.2.0        fs_1.2.6          devtools_2.0.1    hms_0.4.2         triebeard_0.3.0   classInt_0.3-1    rprojroot_1.3-2   grid_3.5.2        glue_1.3.0        R6_2.3.0         
[37] processx_3.2.1    sessioninfo_1.1.1 sp_1.3-1          callr_3.1.1       readr_1.3.1       magrittr_1.5      urltools_1.7.1    units_0.6-2       codetools_0.2-15  backports_1.1.3   ps_1.3.0          usethis_1.4.0    
[49] assertthat_0.2.0  mime_0.6          stringi_1.2.4     lazyeval_0.2.1    crayon_1.3.4

The following minimal example shows the problem:

library(webmockr)
library(httr)

webmockr::enable("httr")
webmockr::httr_mock()
webmockr::stub_registry_clear()
webmockr::stub_request("get", uri = "http://example.com/?request=minimal") %>%
  webmockr::wi_th(
    headers = list('Accept' = 'application/json, text/xml, application/xml, */*')
  ) %>%
  webmockr::to_return(
    status = 200,
    body = "there is no xml here",
    headers = list("Content-Type" = "application/xml")
  )

.response <- httr::GET(url = "http://example.com/?request=minimal")
.http_type <- httr::http_type(.response)
.content_type <- httr::headers(.response)[["Content-Type"]]
.content_type_lc <- httr::headers(.response)[["content-type"]]
cat(paste0("Are the following values '", .http_type, "', '", .content_type_lc, "' and '", .content_type, "' equal? ", .http_type == .content_type_lc, "\n"))
webmockr::disable("httr")

Output when executed:

Are the following values 'application/octet-stream', 'application/xml' and '' equal? FALSE

The correct value is returned by httr::headers. httr::http_type does more than only reading the content-type header.

[EHJ-52n]

@sckott
Any updates on this issue? Did you have time for taking a look? Can I support you anyhow?
Kind regards!

[EHJ-52n]

httr::http_type is checking with uppercase for the correct header: Content-Type and not content-type:

http_type <- function(x) {
  stopifnot(is.response(x))

  type <- x$headers[["Content-Type"]] %||%
    mime::guess_type(x$url, empty = "application/octet-stream")

  parse_media(type)$complete
}

Using the example script from above, it seems that webmockr or httr sets the value with lowercase:

> httr::headers(.response)
$`content-type`
[1] "application/xml"

[sckott]

thanks for this. i was away for a family event. I'll have a look

[sckott]

i can replicate your problem with that older version of webmockr - it has since been fixed - see release notes for the current version on cran https://github.com/ropensci/webmockr/releases/tag/v0.3.4 - let me know if that works

[sckott]

did you test it @EHJ-52n ?

[sckott]

@EHJ-52n ?

[EHJ-52n]

@sckott I have this check on my stack but will not be able to work on this before next week, hence be patient.

Thanks for the reminders!