WebServer - socket won't close?

>OK, I am stumped.
>
>I have a web server set up. It serves a page, via a Servlet; the
>response goes to the client (wget or firefox), and then the client
>hangs, presumably expecting the response to end when the connection is
>closed. However, as far as gst is concerned, the socket has been closed.
>
>I have confirmed that the response has gone to the client, and I've
>confirmed that the socket has been closed by putting debug messages into
>FileDescriptor >> #close (the return value of the 'fileOp: 1' is 0).
>
>Once gst terminates, the client comes back to life, so it seems to me
>that the socket is not actually getting closed, but I can't work out why.
>
>Any help or suggestions would be appreciated.
>
>Mike
>
>
>_______________________________________________
>help-smalltalk mailing list
>[hidden email]
>http://lists.gnu.org/mailman/listinfo/help-smalltalk

> First, set up a servlet that requires no input ( just a straight GET).
> Then crank up your telnet session and type the following
>
> GET /index.html HTTP/1.1
> Host: 127.0.0.1
>
> This is the same thing as http://127.0.0.1/index.html. You'll substitute
> the page that you're trying to access for the "/index.html" and your
> host name if you're not doing the testing on the box that the webserver
> is running. You should get a dump of the web page on your screen
> followed by the termination of the connection. If you're not getting the
> termination of the telnet session, then you can be sure that the socket
> hasn't been closed by the server.
>
>
>
> At 12:44 AM 1/5/2007 +0000, Mike Anderson wrote:
>> OK, I am stumped.
>>
>> I have a web server set up. It serves a page, via a Servlet; the
>> response goes to the client (wget or firefox), and then the client
>> hangs, presumably expecting the response to end when the connection is
>> closed. However, as far as gst is concerned, the socket has been closed.
>>
>> I have confirmed that the response has gone to the client, and I've
>> confirmed that the socket has been closed by putting debug messages into
>> FileDescriptor >> #close (the return value of the 'fileOp: 1' is 0).
>>
>> Once gst terminates, the client comes back to life, so it seems to me
>> that the socket is not actually getting closed, but I can't work out why.
>>
>> Any help or suggestions would be appreciated.
>>
>> Mike
>>
>>
>> _______________________________________________
>> help-smalltalk mailing list
>> [hidden email]
>> http://lists.gnu.org/mailman/listinfo/help-smalltalk
>
>
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk
>

> OK, I am stumped.
>
> I have a web server set up. It serves a page, via a Servlet; the
> response goes to the client (wget or firefox), and then the client
> hangs, presumably expecting the response to end when the connection is
> closed. However, as far as gst is concerned, the socket has been closed.
>
> I have confirmed that the response has gone to the client, and I've
> confirmed that the socket has been closed by putting debug messages into
> FileDescriptor >> #close (the return value of the 'fileOp: 1' is 0).

>I did this, even though I thought I would get the same result as with
>wget. In fact, I don't get any sign of life from the servlet after the
>message that tells me that the socket is connected.
>
>Maybe I'll roll back to 2.2x and compare behaviour.
>
>Mike
>
>J Pfersich wrote:
> > First, set up a servlet that requires no input ( just a straight GET).
> > Then crank up your telnet session and type the following
> >
> > GET /index.html HTTP/1.1
> > Host: 127.0.0.1
> >
> > This is the same thing as http://127.0.0.1/index.html. You'll substitute
> > the page that you're trying to access for the "/index.html" and your
> > host name if you're not doing the testing on the box that the webserver
> > is running. You should get a dump of the web page on your screen
> > followed by the termination of the connection. If you're not getting the
> > termination of the telnet session, then you can be sure that the socket
> > hasn't been closed by the server.
> >
> >
> >
> > At 12:44 AM 1/5/2007 +0000, Mike Anderson wrote:
> >> OK, I am stumped.
> >>
> >> I have a web server set up. It serves a page, via a Servlet; the
> >> response goes to the client (wget or firefox), and then the client
> >> hangs, presumably expecting the response to end when the connection is
> >> closed. However, as far as gst is concerned, the socket has been closed.
> >>
> >> I have confirmed that the response has gone to the client, and I've
> >> confirmed that the socket has been closed by putting debug messages into
> >> FileDescriptor >> #close (the return value of the 'fileOp: 1' is 0).
> >>
> >> Once gst terminates, the client comes back to life, so it seems to me
> >> that the socket is not actually getting closed, but I can't work out why.
> >>
> >> Any help or suggestions would be appreciated.
> >>
> >> Mike
> >>
> >>
> >> _______________________________________________
> >> help-smalltalk mailing list
> >> [hidden email]
> >> http://lists.gnu.org/mailman/listinfo/help-smalltalk
> >
> >
> >
> > _______________________________________________
> > help-smalltalk mailing list
> > [hidden email]
> > http://lists.gnu.org/mailman/listinfo/help-smalltalk
> >
>
>
>
>_______________________________________________
>help-smalltalk mailing list
>[hidden email]
>http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Mike Anderson wrote:
>> OK, I am stumped.
>>
>> I have a web server set up. It serves a page, via a Servlet; the
>> response goes to the client (wget or firefox), and then the client
>> hangs, presumably expecting the response to end when the connection is
>> closed. However, as far as gst is concerned, the socket has been closed.
>>
>> I have confirmed that the response has gone to the client, and I've
>> confirmed that the socket has been closed by putting debug messages into
>> FileDescriptor >> #close (the return value of the 'fileOp: 1' is 0).
>
> Can you send a strace?  If it's big, gzip it or send it privately.
>
> Paolo