uTorrent is indeed closing the connection, but that's just because the
preceding TCP Packet being sent to from the sever has the flag set to
tell it to do so.
I've done a lot more work since yesterday, and I've managed to find the
cause of the problem! The issue is caused by having a superfluous
carriage return being sent in the HTTP request
Here is a request which will succeed
http://i.imgur.com/8Sjlx.png
Here is a request that will end up in the file ending up being only 8 KB.
http://i.imgur.com/EkrTo.png
It seems that if the request being sent has an extra line feed at the
end, it will cause ICS not to serve the file properly.
I reproduced this using Indy HTTP Client and creating an additional
FHTTP.IOHandler.WriteLn(''); on line 2273 in file IdHTTP.pas
I will write to the software developer (uTorrent) to inform them of the
superfluous carriage return, since it does break HTTP 1.1 RFC, but
still, ICS shouldn't choke as a result of this.
Lester
On 10/07/2012 16:58, Angus Robertson - Magenta Systems Ltd wrote:
When the client is Firefox, there is no issue - the file is loaded
successfully. If the client us uTorrent, then the server is
setting the FIN flag too early, resulting in an incomplete file
acquisition.
Regardless of the file type, content or size, the same amount of
data (exactly 8192 bytes) is being transmitted before the FIN flag
is being set.
The ICS code does not send a FIN flag, that's low level TCP stuff.
How do you know uTorrent is not closing the connection early?
How much logging is your web server application doing, does it show the
entire file sent?
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please gotohttp://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website athttp://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
