https://issues.apache.org/bugzilla/show_bug.cgi?id=45687
Summary: mod_charset_lite can drop error responses
Product: Apache httpd-2
Version: 2.3-HEAD
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: mod_charset_lite
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=22480)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22480)
Patch for mod_charset_lite.c
With mod_charset_lite in use, some error responses may not be returned
correctly.
For example, when a request body exceeds the configured LimitRequestBody, a 413
should be returned, but with mod_charset_lite in use, instead a 403 might be
returned (if the URI is forbidden).
To reproduce:
Build with mod_charset_lite (I don't think it gets built by default except on
z/OS).
Include something like this in the configuration:
LoadModule charset_lite_module modules/mod_charset_lite.so
<Location />
CharsetSourceEnc ISO8859-1
CharsetDefault ASCII
LimitRequestBody 2048
</Location>
Submit a POST with a body over 2048 bytes. The response status should be 413,
but it will be something else (e.g. 404).
The underlying cause is mod_charset_lite not treating metadata buckets
specially. When a request body size limit is exceeded, for example, the error
code is communicated by adding an error bucket to the brigade. When it gets to
mod_charset_lite, the module reads the data from it (none) and discards it;
thus the error code never gets to the end of the filter chain and is not sent
back to the client.
I've confirmed the problem on httpd-trunk on Linux, revision 688719. It has
also been seen on older releases on z/OS.
It did not show up in a bugzilla search.
I've come up with a fix, and verified that it compiles without warning on Linux
and solves the problem, so that a 413 response is sent back in the scenario
described above.
A patch is attached for httpd-trunk. I'd welcome comments on it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
