On Fri, Dec 04, 2009 at 08:36:29PM -0700, Lyndon Nerenberg wrote: > >Another example, a little server that allows connections on a single port > >443 for https and ssh. Ideally after reading the "GET" or ssh banner, it > >can just exec whichever server is needed (or fork and exec something like > >netcat). but in fact due to this "already read some data" problem, it has > >to stay alive and copy the data in and out from the other server. > > It shouldn't be too difficult to write a device that allows file descriptors > to be passed from one process to another.
You can do that with unix-domain sockets (or fork, sort of), but I don't think it solves the problem. "fork" also shares fds, but sharing or sending fds does not let me send some extra prefix data to a CGI script's stdin fd then exit and let the CGI script take over reading from my old stdin fd, if that makes any sense. also, obviously I don't want to have to hack every CGI script in existance to make it work. Another possible solution, which would only work with http (so it's not a real solution) would be a function like "read_until" where it would stop reading just before a delimiter "\r\n\r\n" in that case of http. That would not help with the ssh/https and similar multiplexing problems. I think the best way would be my proposed "join" system call. My proposed type of CGI would have an advantage (?) that it presents a bidirectional socket to the script, rather than a file that was already read and saved to disk and a write-only socket. CGI chat over a single http connection for example would be possible (if the browser/client also supported it). Maybe I need to draw some ascii-art. This may be off topic here since it's not specific to plan 9 but I suppose people here may be interested in topics like this. and I don't think I want to brave the lkml right now! "splice" and "sendfile" on Linux are similar contepts to my "join" I guess. I think join is better though! Sam
