Hanging on Project Open, File Open, Status code 504

Hi, and welcome!

Please see the FAQ: What's a reproducible example (`reprex`) and how do I do one? Using a reprex, complete with representative data will attract quicker and more answers. Not required for this kind of problem, though.

Without access to the problem, of course, it's not feasible for me to reproduce the problem. So, I'll have to work from the error message, which traces to the http protocols. A 504 means a timeout: the server was taking too long to respond to a client request.

There seem to be two suspects: 1) the server is choking or 2) an intervening proxy server.

The first is unlikely, because there has been enough time for a problem there to affect a sufficient number of users to have resulted in more reports.

That leaves the second suspect, that between the client and the RStudio server, a proxy server brokers requests.

Here comes the grain of salt warning: it's been 25 years since I once knew a lot about proxy servers.

A proxy server works by getting a request from a client, checking it against its store of already downloaded pages. If it doesn't have a copy, it goes and fetches it from the target server. If it does have a copy, it just asks the target server for the modification date of the requested file. With that information, it either sends its still current copy to the client or fetches the entire file (or maybe by now a diff), overwriting its now-outdated copy and sends it on.

The niche of the proxy server in olden days was to conserve bandwidth between a LAN and the Internet; the less bits transferred the better: Why wait two minutes (at the speeds of those days) downloading a 1MB file that you already have when you can do the version mod date check in just 2 seconds?

One of the configuration issues that became troublesome was the proliferation of clients: Netscape, followed by Internet Explorer and proliferations of others. This made the proxied client server conversation sometimes difficult because the server could become thrown out of kilter by the http request's client header identifying the browser. The initial fix was for the proxy to pass along a lowest common denominator header or, with some tinkering, extract its client's header and send it to the target server as its own.

Where was I? Oh, yes--to cut to the chase, this behavior might well happen from a proxied connection, so if you can try from an unproxied setup.