| Summary: | request body with C-L but early EOF does not error | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Joe Orton <jorton> |
| Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sf |
| Priority: | P2 | Keywords: | FixedInTrunk, PatchAvailable |
| Version: | 2.0-HEAD | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
fix to return an errror when EOS is seen in an incomplete body in ap_http_filter()
updated fix |
||
|
Description
Joe Orton
2005-01-14 14:33:36 UTC
Seems like an issue in core rather than mod_dav. I have a report that mod_dav occasionally deletes files after an unsuccessful upload. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525137 There is the error message "Could not get next bucket brigade [500, #0]" in the error log. Could this be the same issue? The Debian bug is a different issue. It would be possible to fix this in mod_dav by counting the bytes received and comparing with the number in the C-L header. If there is some encoding like chunked or gzip, the C-L will already have been removed, so no problem there. Or should the core / some input filter do the counting and return an error when mod_dav tries to read the missing data? Doesn't mod_dav get an error message (at least a timeout error) if it tries to read from the input filter chain and no more data is present? mod_dav just reads until it sees an EOS bucket. It ignores all metadata buckets. Is there some error bucket when the post body is too short that mod_dav could use to detect the error? (In reply to comment #6) > mod_dav just reads until it sees an EOS bucket. > > It ignores all metadata buckets. Is there some error bucket when the post body > is too short that mod_dav could use to detect the error? No, but if not all content was sent it shouldn't see an EOS bucket. Instead if the content is not sent completely ap_get_brigade should return an error (most likely a timeout). And in fact it does (see line 978 of mod_dav.c on trunk). And ap_xml_parse_input does as well. (In reply to comment #7) > No, but if not all content was sent it shouldn't see an EOS bucket. Instead if > the content is not sent completely ap_get_brigade should return an error (most > likely a timeout). ok, then the bug is in the input filter. I was under the (wrong) impression that this bug only appears if C-L is given. But it also appears with chunked encoding if the first chunk is transferred completely and the body is truncated later. Created attachment 23936 [details]
fix to return an errror when EOS is seen in an incomplete body in ap_http_filter()
this seems to fix the issue (haven't done much testing, though)
(In reply to comment #9) > Created an attachment (id=23936) [details] > fix to return an errror when EOS is seen in an incomplete body in > ap_http_filter() > > this seems to fix the issue (haven't done much testing, though) Basicly looks good. IMHO it is safe to assume that if there is an EOS bucket in the brigade then it is the last bucket. Thus you can safe the loop and just check if the last bucket is an EOS bucket. Created attachment 23944 [details]
updated fix
Thanks. It works without the loop, too.
Committed to trunk a r792409. Backported to 2.2.x. Should be in the next 2.2 release after 2.2.14. |