httplib continuation packets

Haakon Riiser hakonrk at
Mon Nov 13 14:51:40 CET 2006

[Steve Holden]

> It really does seem quite bizarre that a server should respond 
> differently to the same TCP request when it is split differently into IP 
> datagrams.
> There really is nothing wrong (from a standards point of view) with 
> sending FIN with your last data segment. FIN means "I guarantee to send 
> no more data, and will continue to acknowledge your segments until I see 
> your FIN".

It is the server that sends the FIN.  What happens is this (each
line corresponds to one packet):

  client: POST request headers
  client: POST request body
  server: FIN + ACK

On receiving the FIN + ACK packet, Python gets immediate
end-of-file on the POST request.  Unless the order of the
parameters in the POST request matters (I haven't yet tested this),
I have no other explanation than the fragmentation.  If Ipswitch
bothers to reply to my bug report, I'll look into it.  Otherwise,
I'm not wasting any more time on this -- it's not that big a deal
for me personally, since I have already scripted the stuff I needed
with Perl.

> Are you planning to report this bug to Ipswitch? It certainly sounds 
> like someone should.

I quickly browsed through, but couldn't find any good
place to submit bugs.  I ended up using the product feedback web
form.  Wrote a one-line summary, and referred to this thread on
Google Groups.


More information about the Python-list mailing list