Re: hallam@w3.org: Netscape Bug or KeepAlive Feature ?

Well, my client's staff and I have spend something between 40 and 200
person hours tracking down and resolving a problem in our server like
product caused by these two bytes which we didn't realize existed.

If only I'd been current on my e'mail .... >-:). The symptom was that
our code running on Win/95's winsock would leave the two bytes hanging
and close the connection. Since the winsock stack would know it had
two unreceived bytes, it would apparently do a RST instead of FIN.
This resulted in NETSCAPE complaining about the connection being
reset by the peer.

Interstingly, if we inserted a delay before the close, then apparently
NETSCAPE would close first and never complain. I have no idea what
stimulated the thought that it might be outstanding receive data
which caused the problem we were seeing but we tried alomst everything
else first.

In summary, I'm not sure it would be practical to change the content
length or remove the characters but their existance surely *MUST* be
documented, and if perchance we have to make more edits on 1.0 we 
should add a comment there as well.

My inclination is to document the content as being followed by optional
trailers whose end is indicated by a NULL line. Current programs and CGIS
keep working and new applications which might expect such trailers
can work as well.

perl code *CAN* be written to not require trailing CR/LF but it is
more complex so new applications could be made to work.

Dave Morris

On Mon, 4 Mar 1996 hallam@w3.org wrote:

> 
> >I think it would break binary files in weird ways.  For instance
> >transfering an executable would cause it to gain 2 bytes on
> >every transfer.  It would certainly break anything that contained
> >a checksum.
> 
> I wasn't suggesting this. I was suggesting that we change the 
> spec for www-url-encoded-form. I would not want to change the way 
> binary files are transmitted!
> 
> The problem is that netscape is saying it is sending a content length of 36 
> bytes but actually transfering 38. This is a bug IMHO. Whenever a length of 36 
> is stated it should mean 36.
> 
> If Netscape is sending a bogus CRLF after binary files then I would expect 
> problems to arise in any case. 
> 
> 	Phill
>

Received on Tuesday, 12 March 1996 23:09:18 UTC