I currently run my RShiny apps in AWS ECS in containers I build with a Dockerfile using the rocker/shiny base image.
I deploy my applications in a test and a prod environment. The prod environment has more WAF rules that I must follow to be compliant with my organization's standards.
The apps work in test but fail in prod. I have learned that the SockJS POST is being blocked by the Prod WAF because of its "content-type header is NULL" policy.
Taking a closer look, in production, the keep-alive POST requests coming from SockJS have no response headers, causing the POST to fail and the app to continuously retry to establish a connection, only to be blocked over and over.
In the working test environment, I can see that these keep-alive requests start with 0 response headers:
And 25 seconds later, the request is fulfilled with a 200 response and a new request is open. The fulfilled request now has 19 response headers including content-type.
This repeats every 25 seconds. I see in the shiny-server docs that there is a shiny-server.conf parameter sockjs_heartbeat_delay that defaults to 25 seconds.
Unfortunately this is where my knowledge drops off. The questions I hope to answer are:
- Am I correct in thinking that it could be possible to add the content-type header to these SockJS requests before they resolve?
- Is there a shiny-server.conf parameter that can be used to add this header, remove these keep-alive requests, or use a different protocol to xhr that works differently with these heartbeat requests?
- Am I able to edit the source code of shiny-server or SockJS from within my rocker/shiny docker container? If so, where can I add a line to add the content-type header to my request?
Environment specs:
Base image rocker/shiny:latest
Shiny Server v1.5.21.1004
Node.js v16.18.1
Ubuntu 20.04.5