Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: 4 Aug 2003 10:57:47 -0000
Message-ID: <20030804105747.12.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 22104] New:  -
    mod_deflate does not change Content-Length, breaks DAV file upload via PUT

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22104>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22104

mod_deflate does not change Content-Length, breaks DAV file upload via PUT

           Summary: mod_deflate does not change Content-Length, breaks DAV
                    file upload via PUT
           Product: Apache httpd-2.0
           Version: 2.0.47
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: mod_deflate
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: tim@robbins.dropbear.id.au


Although it is well documented that mod_deflate does not modify the Content-
Length header when decoding a gzip-compressed message body, the incorrect value 
seems to confuse mod_dav -- when I try to upload a compressed message body with 
the PUT method, mod_dav returns a 400 Bad Request error, and this message 
appears in the log:

[Mon Aug 04 19:49:25 2003] [error] [client 192.168.0.144] An error occurred 
while reading the request body.  [400, #0]

To test, I'm PUT'ing the output of "echo test | gzip -9c". What happens is that 
dav_method_put()'s first call to ap_get_client_block() returns 5 (strlen
("test\n")), but then it calls ap_get_client_block() again, and it returns -1 
to signal an error. I believe this is because it's expecting more data.

I'm not sure how to solve this problem. It's probably not a great idea to 
buffer the whole body in memory then fix up the Content-Length header after 
decompressing it all, so perhaps mod_deflate could fake up a "chunked"-encoded 
body, putting each block of data returned from zlib into a new chunk, and 
signalling EOF with a 0-length chunk. I'm not familiar with the internals of 
the Apache httpd, so I'm not sure.

I'm filing this as "Enhancement" because although the problem is documented, it 
would be really nice to be able to use PUT requests w/ gzip-compressed bodies.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org