Been digging a bit to try to understand the BodyReader and abort conditions, but it's scary.
Bug #1806 (and it's merged spinoff 1807). Something about this design smells broken, apart from it not working proper (currently either stalling or asserting depending on the conditions). Who should really be responsible for sucking that remaining request body content? The BodyReader or clientReadRequest? For me it feels more natural if it's the BodyReader who sucks the body, keeping clientReadRequest clean. Things noted: a) There is reference count dependent abort conditions in the BodyReader code. This won't work (as is noted in comments already), and even if it's made to work what the current code tries to do there is quite useless as it would only trigger on connection close, and then all it does is to discard the remaining already read data which is just about to be freed.. b) There is no clear responsibility for who is supposed to drain the body of (server-side) aborted request. c) Equally there is no clear responsibility for kicking request processing alive again after the request body has been drained. There may be pipelined requests sitting in the in buffer already. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
