[e2e] HTTP over a half-closed TCP, a bug or ...?

[Jianping Pan]

Was in the thread ``[e2e] RFI: Microsoft accused of TCP standards 
violation''. Subject is changed since the things discussed here
are no longer to support the original claim.

On Monday 06 January 2003 08:18 pm, Ramesh Shankar wrote:
> Perhaps I am not too familiar with the dump formats, but how is this
> supposed to show the establishment of an HTTP session without going

Take a look on the second HTTP request to the same server.
The client tries to send the request and anticipates to
receive the reply over a half-closed TCP connection used 
in a previous HTTP session. This is observed for a Netscape
browser on the Unix platform with an Apache server.

Other people might observe the similar behaviors for other
combination of Web browsers and servers. 

Possible causes (no solid proof yet! just in the course
to find a *reason* why this behavior was there.)
  + a careless programmer mismatches the HTTP and the
	socket-interfaced TCP semantics
  + an intentional design with the hope that the server
	can pick it and resume from a half-closed TCP 
	connection. (Dangerous thought!!! no backing yet)
  + something else ...

> through a 3-way handshake? I am assuming "S" stands for SYN, "P" for
> push and "F" for FIN. As I see it we have a case of a browser expecting
> a persistent connection HTTP-server while the server is non-persistent
> or alternately, persistent, but kicking off the client anyway.

Client already claimed HTTP/1.0 and there is no reason
for it playing against the rule it declares.

>
> The client side's TCP ACKs the FIN (which is done by the TCP stack,
> nothing to do with the browser client) and the client doesn't know that
> the server is not willing to receive anything more on the HTTP session

Actually the server can receive incoming data (request)
at that moment, but no longer send outgoing *new* data 
(reply) as the client wishes.

> and so gets a reset from the server's TCP stack (as the server side has
> presumably done a full close) when it sends data. Hence, the client

However, the server might think differently. Since its
FIN has been ACKed and close() returns, it either waits
for client's FIN or thinks client's FIN is lost and being
retransmitted soon. In the collected tcpdump, apparently
the server does not have interest in the new request at all.

> establishes another connection which can be clearly seen by the SYN and
> the new client side port number (34154 instead of 34154).
>
> Apart from all these, I don't understand how one could do guess work and
> establish a TCP session when data are received without any 3-way
> handshake. NATs would drop on the floor such packets, for example! What
> would be the sender's ACK #? What about the TCP options setup during SYN?
>

This is for the *second* request to the same server. If 
(big, big assumption!!!) the server can pick the second 
request and resume from the half-closed connection, and 
if the client can also receive and pop new reply to 
applications, the second request/reply actually escapes
the 3-way handshake. Yes, there're additional work on
timers and windows, etc.. It is do-able. Certainly, it
violates a lot of things. I do not have the trace now
to say it exists, but I really do not have anything
that I can say it does not or will not exist.

> I would suspect that someone may have seen the trace on a an already
> established persistent, but idle connection and speculated that TCP
> 3-way handshake is being bypassed.
>
> If someone were that desperate, I would expect them to send the GET
> along with the SYN and the server side to send the data along with FIN
> in the SYN-ACK for non-persistent connections!

It's possible for the raw TCP to piggyback the data
in the first SYN, but the receiver has to wait the
second ACK (after the connection is established) 
to deliver the data to applications. But this is 
a bit impossible for the socket interfaced TCP.

Again, this is out of the scope of end2end, and I 
hope to take the further discussion off end2end-
interest, either being offline discussion or moving 
to an appropriate mail list, unless other people 
have different thoughts.


Best regards,

Jianping

>
> Thanks,
>
> S.R.
>