Hi,
Well, according to the CB code, the headers should be included (at least the default "Content-Type: text/html") even if we don't add anything explicitly.
I tried to change {stream, StreamGen, {0, 64}} to {stream, StreamGen, {0, 64}, [{"Content-Type", "text/plain"}]}, but it didn't help.
If I call the CB with cURL in verbose mode, I can see all the headers I've passed from the controller. If I call it via Nginx, it gives me a HTTP 502 error.
The background story is that we have a CB-based application server that lives inside a per-customer Docker container while the Nginx is just a vhost-proxy with dynamically generated configuration for each of the Docker container's port (randomly assigned).
Each of the containers is available through SSH ("legacy" character-cell based application; also proxified, so we cannot upload anything with sftp/scp) and HTTP (mostly reporting), so if we want to upload a hotfix patch package (instead of rebooting the container from a new Docker image), the only way is to upload it over HTTP.
But in that case, we want to write some progress messages (output of the installation procedure; we don't upgrade just an Erlang stuff which is almost clean and silent), so we have a controller that runs an OS command via Erlang port and stream the command's output back to the client.
This worked perfectly whenever we had an on-site deployment with no HTTP proxy, but on the "hosting", there's no way how to live without HTTP proxy... (which was originally Apache, but because of WebSockets and other reasons, we've switched to Nginx).
So the base facts are:
- I think headers are sent correctly
- Nginx has no direct access to the CB's filesystem, even if the streamed content was a file (it is not, in this case)
- we cannot simply follow the CB upstream since we have some custom patches (not just in CB, but also in several dependency projects). Some of them cannot be merged to the upstream for multiple reasons... It could be fixed, but would require some time what's something I don't have at the moment :-(
Tom