Proxy support broken, cannot install any packages anymore

After updating R and RStudio we cannot install any packages anymore.

Windows Server 2019
Proxy: McAfee MWG, configuration using PAC Script
RStudio Community
Global Options: Use Internet Explorer library/proxy for HTTP is set

install.packages("DT")
Warning in install.packages :
kann nicht auf den Index für das Repository Index of /src/contrib zugreifen:
cannot open URL 'https://cran.rstudio.com/src/contrib/PACKAGES'

No connection attempt is seen on the proxy.

Before (Working):
R 4.1.1
RStudio 1.4.1717

Now (Broken):
R 4.2.1
RStudio 2022.07.1+554

Hi,

Try to verify the following configuration was uncheckeded : Global option -> Packages->Use secure download method for HTTP.
You just have to uncheck it

uncheck this option does not change anything. Does not work either.

As a workaround I set up a Nexus Repository OSS now but I can set this only as a fallback option (Secondary Repo). This means I have to wait a long time for every package as it first tries the direct non working way first.

Do you try this solution ?

What should I try from this thread? I can open the links with the browser without any issues.
Having to set http_proxy variables is not an option... and I didn't have success with it either.

The point is - it was working fine before the update....

Perhaps you could try to downgrade to 4.1 for R version ?

This problem is caused by a change in R not RStudio. The R 4.2.0 changelog (link) says the following:

  • The (non-default and deprecated) method = "internal" for download.file() and url() no longer supports ‘⁠http://⁠’ nor ‘⁠ftp://⁠’ URIs. (It is used only for ‘⁠file://⁠’ URIs.)On Windows, download.file(method = "wininet") no longer supports ‘⁠ftp://⁠’ URIs. (It is no longer the default method, which is "libcurl" and does.)On Windows, the deprecated method = "wininet" now gives a warning for ‘⁠http://⁠’ and ‘⁠https://⁠’ URIs for both download.file() and url(). (It is no longer the default method.)

I've seen this on a corporate network and I can work around it by adding method = "wininet" when downloading packages eg install.packages("tidyverse", method = "wininet"). You'll get a warning but you should be able to use that until R4.3 comes out. Hopefully, we'll be able to get a fix before then.

Ah, thank you very much for that information!

Any chance to make our local Nexus Repository a primary repo in case this isn't fixed soon?
And to set this option when installing RStudio?

yes, it works with method = "wininet"... But curl should be able to use proxies as well even with kerberos auth ... I wonder what's wrong there.

install.packages("tidyverse", method = "wininet")
Warning in install.packages :
the 'wininet' method is deprecated for http:// and https:// URLs
trying URL 'http://cran.rstudio.com/bin/windows/contrib/4.2/tidyverse_1.3.2.zip'
Content type 'application/zip' length 428926 bytes (418 KB)
downloaded 418 KB

Paket ‘tidyverse’ erfolgreich ausgepackt und MD5 Summen abgeglichen

I think I have the same issue on Linux system ( Ubuntu 22.04 LTS). Do you know what method I have to choose to solve this?
I'm using the last version of Rstudio with R 4.2.1.

As far as I know nothing changed on Linux between R4.1 and R4.2 regarding download.file. Perhaps it's a similar symptom but a different issue?

Yes you're right. I downgrade to R version 4.1.2 without any effect. I will open another topic.
Thanks for your help.

My corporate PC is locked down so there is limited troubleshooting that I've been able to do. I don't have a problem on two other Windows 10 PCs that I use at home with the same RStudio and R versions - no pac file or proxy and nothing being blocked on my firewall. Something in the R4.2 change is broken for certain Windows setups.

Related topic here: PSA: R 4.1.x to 4.2.x CRAN not reachable. Observations and one fix - #2 by greg

My guess is that curl doesn't retrieve the proxy settings from windows.

And using http[s]_proxy environment variables is not an option. I need something which works out of the box.
I already had users set these variables on their systems and then they started to wonder why other applications didn't work anymore (like Postman), or why access to other internet sites was broken as we have direct connections to other internal sites which must not go though the proxy.

This is all set up with the proxy script and will be broken when you use these environment variables.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.