Fwd: kio: slave process dies when using https

[Michael Cardenas]

FYI, our testers say that they still see the bug when moving from a http to an https
page. 

Also our web developers say that any time an https form posts data to itself and then writes a cookie, they get the bug.

This is with keep-alive connections disabled for ssl, but sending the
keep-alive header being sent for http connections. 

On Fri, May 31, 2002 at 07:51:18PM -0400, Dawit A. wrote:
> On Friday 31 May 2002 12:42, you wrote:
> > Well, it seems like the working fix is to disable keep alive connections
> > for ssl, as your patch did, since turning on this header didn't solve
> > the problem. I'll be happy to turn the keep alive header off. Also, it
> > sounds like the 1.1 spec doesn't explicitly say you shouldn't send that
> > header, just that it's not necessary.
> 
> Read closely, eg. section 19.6.2 of RFC 2616.  You have to be very careful how 
> and when you use the old style "Persistent" connection headers since you will 
> have no idea what kind of server the end user would be connected to before 
> you get the first response back.  The original attempt to bolt "persistent 
> connection" onto the HTTP/1.0 specs caused more of a problems than it was 
> worth.  Anyways, we disabled that support on purpose (read: bug reports from 
> people using proxy servers).
> 
> > I think the long term solution for this is to fix tcpslavebase.cpp,
> > isConnectionValid. We were encountering a situation where the server had
> > closed the connection, but isConnectionValid still returned true, so the
> > kio slave wrote to the socket, causing a SIGPIPE. isConnectionValid uses
> > this line:
> >
> >       retval = recv(m_iSock, buffer, 80, MSG_PEEK);
> >
> > to see if the connection is still open. From the documentation, a zero
> > return value from this message only means that there's no pending data
> > to be read, not that the connection is closed. Maybe we can use
> > getpeername() to see if the connection is still valid, or maybe that's too
> > slow.
> 
> Yes, the problem is indeed this function.  I am currently working on this to 
> see if we can do a better job there.  Ultimately though something needs to be 
> done to ensure that a SIGPIPE does not force the io-slave to exit, but 
> instead forces it to retry first or send the appropriate error message 
> latter.
> 
> Regards,
> Dawit A.
> 
> 
> 

-- 
michael cardenas
lead windows compatibility engineer
lindows.com
.
hyperpoem.net
.
"Be the change you want to see in the world."
-Mahatma Gandhi