W3C home > Mailing lists > Public > www-jigsaw@w3.org > January to February 1997

handling requests [was CGI needs to close connection]

From: Anselm Baird_Smith <abaird@www43.inria.fr>
Date: Wed, 26 Feb 1997 08:50:18 +0100 (MET)
Message-Id: <199702260750.IAA00838@www43.inria.fr>
To: bpm@techapp.com
Cc: www-jigsaw@w3.org
Brian Millett writes:
 > Anselm,
 > 	I've started back up looking at the fastCGI problem of Jigsaw not
 > closing the connection after the fastCGI application has been
 > invoked.  But I failed to keep good notes on what class handles the
 > reply back to the client.  I'm guessing that the a5 version might have
 > changed also from the a3 release.
 > 
 > The problem is not in the execution of the CgiResource that maps to
 > the fastCGI, but in the first invocation of the resource, the
 > connection hangs.  If I stop the connection with Netscape's stop
 > button, then each subsequent invocation works just fine.  The first
 > seems to not want to let go.
 > 
 > Can you help with some pointers in tracing the life of a request when
 > it comes in till it terminates?  That way I can go look in the right
 > spot.

A breif sketch of what happens (1.0alpha5):

. w3c.jigsaw.http.httpd 
    Loops (the run method) until there is a new connection to
    accept. Once a connection is detected, it is handed out straight
    to an object implementing the ClientFactory (same package)
    interface. 
. w3c.jigsaw.http.ClientFactory
    Has the duty of creating a sub-class of Client (same package), to
    wrap that connection into an object that will manage it. I am
    assuming that subclass is w3c.jigsaw.http.socket.SocketClient for
    the rest of explanations.
. w3c.jigsaw.http.socket.SocketClient
    Acquire a thread from its thread cache, which runs it 'run'
    method. This method setup a wrapper on top of the socket input
    stream for reading an HTTP request (which happens in
    w3c.jigsaw.http.Client:startConnection) 
. w3c.jigsaw.http.Client:startConnection
    Gets the request in (this is really the 'main loop' and calls up a
    method of w3c.jigsaw.http.httpd:perform to perform it.
. perform:
    The preform method (an other interesting place to look at) acts in
    two stages:
        a) Lookup the target resource (given the url in the request)
        b) Invoke the perform method of that resource
. w3c.jigsaw.resources.HTTPResource:perform
    Has been splitted as of 1.0alpha5 (thanks Alex ;-) , proceeds in
    three stages: 
        a) Invoke ingoing filters
        b) dispatch (actually calls the get/put/post, etc method)
        c) invoke outgoing filters
  This stage results in a Reply object
. w3c.jigsaw.http.Client
    Emits back the reply. The connection is then checked to see if it
    can be kept open. Iff:
        The reply is 1.0, the request had a Connection: Keep-Alive,
        and the reply had a content length
        The reply is 1.1 (the request was 1.1) if it didn't had a
        content lenth, the stream was chunked encoded, the connection
        is *always* kept open *except* if reply.setKeepConnection was
        explictly called during previous stages with false.
        [best is to look at Client:startConnection for full details]
    Connection is kept open.

In the case of a CGI script, it is likely that (assuming a HTTP/1.0
request) the connection gets closed since the reply will not pass
first test above (no content length).

Hope this helps, if not could you send the dump obtained through
running jigsaw with -trace (this will help me)

Anselm.
Received on Wednesday, 26 February 1997 02:50:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:26 GMT