Forum OpenACS Development: Re: bgdelivery and https
Secondly, i wonder, how bgdelivery is coming into play, since bgdelivery does not serve files via https (there is no way to transfer the openssl context to another thread). The recommended setup is to use a proxy like nginx handling https, then the backend sees just http, and bgdelivery helps to provide scalability.
With regard to nginx, we have begun setting that up and that will be the road we continue down. There are numerous documents written by community members floating around about using nginx to server /resources files as well as content-repository-content-files. Were you just simplifying the recommendation or do you not bother with any of that? I'm also curious how else you utilize nginx in your environment (which I know is pretty large and sees heavy utilization). There are a couple of other areas that seem interesting - chunked input support and byte range requests. Are you using those nginx features to compliment aolserver?
i would not recommend to serve content repository files via nginx, at least if these files are not public. There are ways to integrate external authentication schemes into nginx, but we have not tried this. Background delivery is scaling great, there is no need to hand this over to nginx (yesterday, our server delivered 240 GB of data, 180GB were delivered from the backend). Right now, 32 files are concurrently spooled via bgdelivery.
We do not use any special nginx modules. h264 streaming is performed via an aolserver module and bgdelivery, chunked input and range requests are handled via naviserver. We are using naviserver in production since more than a year. Most our updates/fixes/extensions for naviserver are in the public repository at bitkeeper, we have still to clean up openacs integration layer, but we could do this in a month or so.