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
This archive was generated by hypermail pre-2.1.9 : Wed Nov 01 2006 - 12:00:06 MST