In message <Pine.GSO.4.44.0203241341020.28805-200000@peta.cs.auc.dk>,
`Lars Christensen <larsch@cs.auc.dk>' wrote:
> > This approach seems appropriate to use the threads efficiently.
> > However, it has to be considered about the processing which
> > performed only when connection is established. This problem is
> > appeared in webrick/https.
>
> Second try. This time I select on @listeners and sockets in two seperate
> threads to avoid using @listeners.include?. Also, I removed the timeouts
> on the selects and used a pipe to notify the socket-listening thread when
> a socket is being returned to the main loop.
If TCPSocket is wrapped by another class in run method, this patch
doesn't work well. In my https implementation, SSL session is
established and closed in HTTPServer#run (webrick/https.rb override
this). An instance of SSLSocket is managed by local variable on the
stack, so it cannot be referred again after run method returned.
And, webrick/https is implemented without using start_hook(). It's
reserved for users and never used in builtin classes. For example,
access control with Seki's ACL can be written as follows.
require 'acl'
require 'webrick'
include WEBrick
class HTTPAccessDenied < HTTPServerError; end
MyACL = ACL.new(%w[
deny all
allow 192.168.1.10
allow 127.0.0.1
])
svr = HTTPServer.new(:Port=>2000)
def svr.accept_hook(sock)
addr = sock.peeraddr
unless MyACL.allow_addr?(addr)
raise HTTPAccessDenied, "#{addr[3]}: access denied"
end
end
svr.start
p.s. In CVS version of WEBrick, 408 error which have not read
request-line is ignored.
--
gotoyuzo