On Thursday 14 November 2013 11:32:18 Cedric Blancher wrote: > On 13 November 2013 15:46, Joel Martin wrote: > > On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak wrote: > >> The other problems I see is: > >> How can the script get access to the data returned by accept()? Unlike > >> ksh93 bash4 has no compound variables yet. > >> How can the accept() socket be passed to a child process so that > >> request processing can be passed to a fork()ed child process? > > > > The accept socket is not exposed to the script by this change. > > Why? > > What happens if someone wishes to set more flags on that socket?
does bash even support setting flags on sockets today ? if not, then demanding more than the status quo here is a bit unreasonable. > Or > wishes to have the per-accept() data, like the requester address? Not > all protocols (say, NFS or non-krb5 rsh protocols) embed the request > address in the request itself, and if you look at the Apache archives > it can even be considered an attack of the address from accept() and > in the request do not match (requester spoofing attack). > > So far I can see the server socket you implemented is only barely > enough to do a HTTP server, and not even an good one. it's fsckin bash for fsck sake. it's never going to be able to be a "good" server. it's meant for quick hacks. if you have an important service utilizing this stuff, then your infrastructure deserves to burn to the ground when it fails :P. > Maybe a better way would be to implement something which creates a > server socket for accept, and then have a poll builtin (coincidentally > ksh93v- has a very nice poll(1) implementation) which can be used to > wait both on the accept socket and the sockets returned by accept. If > the accept sockets returns an event you could use something like > /dev/tcpserver/nextaccept to open to obtain the next socket returned > by accept(), and store the accept() data in an env variable. adding other features like this doesn't sound like a bad idea at all, but it also doesn't sound like it should preclude a simple & useful extension to existing bash code. -mike
signature.asc
Description: This is a digitally signed message part.
