Author demian.brecht
Recipients demian.brecht
Date 2015-01-22.17:00:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za>
In-reply-to
Content
There are a couple of small issues with the determination of whether or not a request can fit in a single TCP/IP packet in http.client.

1. The MSS is hardcoded
2. The TCP data size is calculated as only the message body. This is incorrect as the size of the HTTP headers should also be accounted for.

I suggest two changes be made to fix this:

1. The MSS is retrieved (on platforms that support it) using getsockopt(socket.IPPROTO_TCP, socket.TCP_MAXSEG). If the platform doesn't support it (i.e. Windows), it should default to the currently hardcoded value. This does add a requirement for a connection to be established prior to this calculation (currently the connection is only established after).
2. The HTTP headers are added to the full payload size calculation when compared against the connection's MSS value.

This is still a best guess based on minimal TCP/IP header sizes, but if options or extension headers are used, the packet may still be split at the lower levels. This is fine because what we're trying to avoid is multiple send()s where the payload is less than the MSS.
History
Date User Action Args
2015-01-22 17:00:35demian.brechtsetrecipients: + demian.brecht
2015-01-22 17:00:35demian.brechtsetmessageid: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za>
2015-01-22 17:00:35demian.brechtlinkissue23302 messages
2015-01-22 17:00:34demian.brechtcreate