Thanks for the interesting idea. I have to admit, I'm perplexed as to
why you didn't just use a traditional web server to serve such files.
I think I'll take this opportunity to solicit community input on this
general issue, which has bothered me for a while. People seem to be
assuming that it is axiomatically impossible or clearly undesirable that
an Ur/Web application must always be running in the context of a web
server like Apache. Why is that? Unsurprisingly, in such a setting, it
is quite trivial to do anything that web servers usually do. As far as
I understand, almost all real-world web applications run in the context
of Apache or similar servers, or at least they did 5 years ago.
There are at least three easy modes for running Ur/Web applications with
Apache, lighttpd, etc.:
1) FastCGI process started and stopped automatically by the web server.
I recommend this mode for production deployments.
2) Main web server proxies appropriate HTTP requests to the
application. I recommend this mode for development.
3) CGI program invoked by main web server. This is a pretty retro
option that is rarely appropriate today.
The Ur/Web manual contains example configuration for some of these
strategies, and I could add more, if I've been mistakenly assuming that
some small piece of Apache knowledge is widely enough known that it's
not a big deal for any Ur/Web user to apply it in setting up a
development/production environment.
On 08/01/2014 03:47 AM, Sergey Mironov wrote:
Hi, Adam. Since you have published your file-serving extension, I'd
like to share my old code for solving similar task.
The idea is to be able to pickpocket the client-connection socket from
the urweb and pass it to some standalone application which would use
it to serve large file. I am using it to send firmware tarballs
(approx 20-50 Mb in size) to the clients.
Here is how it works in more details:
1. The Ur/Web server sets the 'sock' field of the uw_context (see the patch)
2. The program calls the detachSocket function which extracts this
field and prevents Ur/Web from writing anything to this socket.
3. The client program starts new process (via my urweb-callback FFI
library) and passes the socket to it via command line (UNIX layer
makes sure that child processes inherit opened handles correctly)
4. The child process does it job to sending it's content to client
That's it. I'm not asking you to include this modification into the
Ur/Web, just want to share the approach.
Regards,
Sergey
Demo - https://github.com/grwlf/urweb-detach
Patch -
https://github.com/grwlf/urweb-detach/blob/master/1_of_1_Introduce__Detach__mechanism_.patch
(and in attachment)
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
