We're migrating our public-facing Shiny Server (Pro) to RStudio Connect. We have four applications that have been around for years -- a couple of the applications have multiple URLs out in the wild (referenced in documentation, word of mouth, people's bookmarks, etc.) that on Shiny Server we can easily redirect to the 'live' application by setting HTTP 301 and 302 redirects in shiny-server.conf.
Glad to hear about your migration to RStudio Connect - hopefully Connect will help a lot in the long term.
Unfortunately, in the short term, this is a feature request for RStudio Connect as there is no real method for setting the redirects you are discussing in RStudio Connect. The "HttpRedirect" setting is designed to upgrade HTTP requests to HTTPS, not perform arbitrary redirection of paths.
Unfortunately, this does not help with backwards compatibility, so a couple of options:
leave Shiny Server in place at the old domain and set redirects to RStudio Connect on a new domain
create "placeholder" content on RStudio Connect at the "old" vanity URLs / path with links to the "new" location.
use an nginx, apache, or other reverse proxy in front of your services to get supreme control over path routing
The first is a very short term solution (you don't want to maintain Shiny Server Pro just for backwards compatibility of paths). The second is the simplest solution that involves only RStudio Connect. And the third is the most complex, but also the most flexible.
On the second, if you choose to go that direction, you can even build HTML documents that force a path redirect.
For instance, you would publish a HTML document to Connect with vanity path domain.org/oldURL and have it redirect to domain.org/newURL. Note that this solution will only work for paths below the "root" of the Connect server. For more flexible path routing, you will unfortunately need a reverse proxy (option 3).
In the meantime, I will definitely submit your feedback for consideration and discussion internally! Do you have questions about the above?
Many thanks for the clear and detailed reply. We've chosen to put nginx in front of Connect to do what we need, and that's a fine solution. The second option seems like a perfectly reasonable kludge, too!
Glad to hear you have a solution! "Perfectly reasonable kludge" is such a wonderful description My specialty! Let us know if we can help with anything else!
My specialty! Let us know if we can help with anything else!