potential change review please

 I've run across some (to me) odd behaviour in a couple of places and
after some investigation I've made some changes that seem to work. Given
that it's been demonstrated that I don't really understand how this
stuff all hangs together I'd appreciate someone reviewing these changes
and commenting.

(1) Non-blocking sockets on WinNT. My connects were failing. My Doc for
WinNT says that I should be prepared to handle EINVAL and WOULDBLOCK as
equivalent to EALREADY. The HTTCP.c module doesn't provide for this. The
change I made was to add an additional state, TCP_CONNECT_PENDING. When
a connect returns WOULDBLOCK the state moves to CONNECT_PENDING. When
the state machine processes CONNECT_PENDING it simply changes the state
to CONNECTED.
    Now AFAIK this should be OK, as a completed connect sets the socket
to write. Now this works fine on my system but can someone tell me if
this is a bad thing for any reason ?

(2) HTTP Post requests. I've followed as best I can the past discussions
and reasons for the timeout before sending the entity but I just don't
see the logic. If we receive a 100-Continue we should immediately send
the entity body. The timer is still good for cases where we don't
receive a 100.
  I modified the HTTPEvent state machine ( HTTP.c around line 1237) so
that if the status returned from HTHost_Read is 100, we call the
postCallBack routine immediately and delete the associated timer. The
timer will still pop in cases where a 100 is not received.
    Again this seems to work fine in my tests so far. Is there a reason
why this is not a good thing ??
        I'll be happy to send anyone the source changes if they'd like a
closer look.

        Thanks,
            G.

Received on Saturday, 10 June 2000 11:36:11 UTC