search

benoitc / gunicorn

gunicorn 'Green Unicorn' is a WSGI HTTP Server for UNIX, fast clients and sleepy applications.
http://www.gunicorn.org
Other
9.88k stars 1.76k forks source link

detect incomplete body before reading next request #3256

Open pajod opened 4 months ago

pajod commented 4 months ago

DO NOT MERGE: The attached patch only checks that we have read the entire expected body after processing is done. It merely assist in testing and demonstrating that there is a problem, it does not prevent replying to truncated input yet.

I wonder if there is a way to approach #3234 with just one length check. We have one NoMoreData now, but it appears we want two variants - a) done reading, and b) unable to read more.

benoitc commented 3 months ago

I don't understand the point there. We don't crash in the midldle of the appliication processing. How is the application supposed to handle such error there?

pajod commented 3 months ago

We don't crash in the middle of the application processing

We do raise InvalidHeaderName when we see something funny in chunked trailer fields. To me that feels like sufficient precedent for demanding that the application (and, where failing that, Gunicorn) can reasonably deal with the result of invalid or truncated input up to and including processing even the very last octet of arbitrary-length input.

EDIT: I have not yet made much progress on determining what "reasonably deal with" means in this context, hence the repro-only state of this PR.

benoitc commented 3 months ago

We don't crash in the middle of the application processing

We do raise InvalidHeaderName when we see something funny in chunked trailer fields. To me that feels like sufficient precedent for demanding that the application (and, where failing that, Gunicorn) can reasonably deal with the result of invalid or truncated input up to and including processing even the very last octet of arbitrary-length input.

fair enough :) please go ahead then :) We shoudl probably document this somewhere also