homepage

I am trying to connect to a server (talouselama.fi) 
using urllib2. The server respond immediately after it 
has received the first package from the client 
(urllib2). Since httplib fragment http requests in a 
request package and subsequent header packages the 
server disregards any header information that is sendt 
using urllib2. I have used ethereal to trace the 
packages for the connection. I can provide a dump if 
necessary.
This problem may well be due to a corruptet tcp/ip 
stack at the server (talouselama.fi) but shouldn't 
urllib handle this if any other browser does. (lynx, 
explorer, opera - no exception)??
/Asle

Logged In: YES 
user_id=6380
Can you explain what you think httplib is doing wrong? Are
you saying that it should buffer the whole request until it
is ready to send it in a single send() request? If so, I
don't think it is httplib's responsibility to fix this --
the server doesn't follow the HTTP protocol (which says
nothing about keeping things together in a single packet),
and its webmaster should be informed of the bug in his site.
Other browsers probably happen to send the whole request in
a single packet.

Logged In: YES 
user_id=152302
I do agree with you that is not httplib's responsibility to fix it. However my opinion is that at least we should try to find a work-around for this type of problem. I would hate being unable to connect to the site just because Python fails.
I have been looking into the possibility that the problem is related to which http version that is used. I used python2.0 in my original experiment and it issued http/1.0 requests. Later on I also tried to connect to the server directly using httplib and HTTPConnection to issue http/1.1 requests but it did not make any difference. The server still responded before httplib had finished its request.
Do you have any suggestions on a work-around?

Logged In: YES 
user_id=31392
I changed httplib to send requests as a single packet in rev
1.60. The change was made to address a performance problem,
but happens to fix the problem you had with the bogus
server, too.