Matt Holt

@coolaj86 Hiya! (I know I just replied on Twitter, but) I disagree with the part about abusing constraints, but I do think you could be right. This is not my...

Thanks for opening an issue! We'll look into this. It's not immediately clear to me what is going on, so I'll need your help to understand it better. Ideally, we...

@kuhnchris Awesome, thanks for setting this up. I'll take a look as soon as I get in the office after the weekend! Meanwhile, you and anyone are welcome to investigate...

Great, thank you for the simpler reproducer! I need to find time to work on this as I'm currently deep in the mud on another complex issue. I'll return to...

@kuhnchris I was able to repro the error with the simpler instructions, will now investigate.

@kuhnchris Oh, this is simple: the Python script is closing the socket before the response is read: ``` ... # Comment those 2 lines to reproduce the problem # response...

@kuhnchris > Well, for low-latency streaming, that's the approach ffmpeg actually takes ffmpeg closes the connection without waiting for or reading a response? I do find that very odd --...

I see. So maybe if flush_interval is -1, we should always finish writing to the backend even if the client closes the connection.

@kuhnchris This is a little tricky though, the standard library's `http.Transport` is returning the `context.Canceled` error - in other words, it's not our code that streams back the response. I...

I haven't been able to actually prove this but based on some experiments with replacing the request's context with one that doesn't get canceled when the client disconnects, I believe...