Buggy TCP implementations. Was: ISSUE: MUST a client wait for 100 when doing PUT or POST requests?

David Morris, on 11 Jun 1997 asserts: 
>It is my impression that is it difficult or impossible to do a reliable
>1/2 close on all TCP/IP implementations. Unless my memory is all wet, 
>solving a problem with an approach which doesn't work isn't helpful.

Care for some water?

By this line of reasoning, we are left with what is likely the null set
of TCP; those features that have no implementation bugs on any platform, 
in any release.  

As John Klensin (formerly area director) pointed out over a year ago to a 
number of us,  this is not a productive place to be in, and it isn't clear 
that the  Web would work at all if it had taken this minimalist "avoid all 
known bugs" approach.

Closing 1/2 the connection works properly today on most
platforms, and due to the efforts of the Apache group all vendors that
have this bug, at least on UNIX market, know they have the bug in time to
fix them before 1.1 is widespread (they should have known about the bug
for over 4 months already).  The Web, and Apache (the most common
server on the public Internet), have enough intertia
to see that this class of bug gets fixed in a timely fashion.  In Microsoft's
case, the Web server implementer happens to be the same person as who 
implemented their TCP implementation, so I'm not worried here.  (Care to
correct me, Henry?). Dunno about the TCP on Mac though.

In any case, we seem to have good reason to believe that the 1/2 close
solution is indeed a viable solution (i.e. some of us have done significant
homework in the area since we became aware of the bug in some people's TCP's).
Lets have a bit of faith that the TCP implementers will fix their bugs...
				- Jim

Received on Wednesday, 11 June 1997 12:19:22 UTC