git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Intermittent bug with asyncio and MS Edge


On 2020-03-22 12:11 PM, Chris Angelico wrote:
> On Sun, Mar 22, 2020 at 8:30 PM Frank Millman <frank at chagford.com> wrote:
>>
>> On 2020-03-22 10:45 AM, Chris Angelico wrote:
> 
> If you can recreate the problem with a single socket and multiple
> requests, that would be extremely helpful. I also think it's highly
> likely that this is the case.
> 

I am working on a stripped-down version, but I realise there are a few 
things I have not grasped.

Hope you don't mind, but can you scan through what follows and tell me 
if I am on the right lines?

Both the client and the server can send a header with 'Keep-alive', but 
what does it actually mean?

If the client sends it, does that mean that it wants the server to keep 
the connection open, and only close it when the client closes it from 
the other end?

Conversely, if the server sends it, does it mean that it wants the 
client to keep the connection open? If so, under what condition would 
the server close the connection (other than a timeout). Should the 
server only send 'Keep-alive' if it receives 'Keep-alive'?

In my program, when I send a file in response to a GET, I send a header 
with 'Keep-alive', then I send the file, then I close the connection. 
This now seems wrong. It could even be the cause of my bug, but then why 
has it only appeared now? Both Edge and Chrome send 'Keep-alive' headers.

If I am thinking along the right lines, then the exchange should go like 
this -

Client sends request, with 'Keep-alive' header.

Server sends response, but does not close the connection. The server 
should reply with a 'Keep-alive' header. If it does not, the client will 
close the connection, in which case the server will also close.

Assuming that they both send 'Keep-alive', the onus is on the client to 
close the connection when it has no more requests. The server should 
have a timeout in case the client goes away.

Assuming that the above is correct, the client will rely on 
'Content-length' to determine when it has received the entire request. 
If the client has more than one request, it will send the first, wait 
for the response, when fully received as per the 'Content-length' it 
will send the next one, until all requests have been sent and all 
responses received, at which point it will close the connection.

All this assumes only one connection. Alternatively the client could 
open multiple connections for the requests. In that case it would make 
sense to use 'Connection: Close', so that the server can close the 
connection straight away, making it available for reuse.

If this all makes sense, I should write two versions of the client 
program, one using a single connection, and one using a pool of connections.

All comments appreciated!

Frank