You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2014/04/15 12:24:06 UTC

[Bug 46146] deflate_in_filter fails to inflate if CRC/length bytes are not in available stream

https://issues.apache.org/bugzilla/show_bug.cgi?id=46146

--- Comment #12 from Thierry Guérin <t_...@hotmail.com> ---
Hi,
thanks a lot for the fix, I'm PUTting gzipped files and the upload would not
work on some files (on 2.2.x and 2.4.x). So in its current state, sending
gzipped content is indeed unusable; I really apreciate that work is being done
in this area.

However, the patches introduced here unfortunately result in a situation that
is in fact worse with some files (I have attached one):
- before the patches
  * with version 2.2.x, I get an error 500 and a message "Could not get next
bucket brigade  [500, #0]" in the error log. There is no file on the server.
BUT if I retry several times (between 1 and 9 times, this varies), the file
gets correctly written.
  * with version 2.4.x, I get an error 500 and a warning "AH01396: Verification
data not available (bug?)", then an error "An error occurred while reading the
request body (URI: /uploads/curl.xml)  [500, #0]". There is no file on the
server. BUT if I retry several times (more than 20 times, again this varies),
the file gets written, but is truncated (its size varies)
  * with trunk, (before this patch is applied),  I get an error 400 and a
warning "AH01396: Verification data not available (bug?)", then an error "An
error occurred while reading the request body (URI: /uploads/curl.xml)  [400,
#0]". There is no file on the server. I haven't tried multiple times.
- after the patches, there is no message in the error log and a code 201 is
returned BUT the written file is truncated. Its size is always the same.

I have tested version 2.2.27 and 2.4.9 both on Windows & Debian, but the trunk
has only been tested on Debian.

Thz gzip stream is created via a Java program, but the error can be reproduced
with the command 'gzip -n myFile.xml'

To reproduce the problem:
curl -H "Content-Encoding: gzip" --upload-file raw.xml
http://localhost/uploads/

(with raw.xml being the result of the gzip command)

I will attach both the xml file (curl.xml) and its gzipped version (gzip.xml).
Almost any small alteration to the xml file (like adding/removing a space)
solves the problem.

I have added the comment to this bug, because its fix results (in my opinion)
in things being unfotunately worse, but if you think that this belongs in a
separate bug, I'll create one.
Hope this helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org