https://bz.apache.org/bugzilla/show_bug.cgi?id=69975
Bug ID: 69975
Summary: LimitXMLRequestBody Error in *set_limit_xml_req_body
Product: Apache httpd-2
Version: 2.4.66
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
LimitXMLRequestBody should throw an error if the value is non a number.
If you add this to httpd.conf and do httpd -t we get a Syntax OK:
LimitXMLRequestBody abc123
LimitXMLRequestBody 123abc
However if we were to run the exact same test with the following, we get an
error "LimitRequestBody requires a non-negative integer."
LimitRequestBody 123abc
The key to this lies in the difference between how the two functions are
written. See 3754 to 3786. The char *errp does not exist in the second
function, and because it's handling the check differently LimitXMLRequestBody
can be passed a bad value and give a Syntax OK status while LimitRequestBody
will not allow it.
The documentation for both directives expects a number so this does not seem to
be a case where there would be a reason to pass a string in.
Happy to write a patch.
static const char *set_limit_req_body(cmd_parms *cmd, void *conf_,
const char *arg)
{
core_dir_config *conf = conf_;
char *errp;
if (APR_SUCCESS != apr_strtoff(&conf->limit_req_body, arg, &errp, 10)) {
return "LimitRequestBody argument is not parsable.";
}
if (*errp || conf->limit_req_body < 0) {
return "LimitRequestBody requires a non-negative integer.";
}
return NULL;
}
static const char *set_limit_xml_req_body(cmd_parms *cmd, void *conf_,
const char *arg)
{
core_dir_config *conf = conf_;
conf->limit_xml_body = atol(arg);
if (conf->limit_xml_body < 0)
return "LimitXMLRequestBody requires a non-negative integer.";
/* zero is AP_MAX_LIMIT_XML_BODY (implicitly) */
if ((apr_size_t)conf->limit_xml_body > AP_MAX_LIMIT_XML_BODY)
return apr_psprintf(cmd->pool, "LimitXMLRequestBody must not exceed "
"%" APR_SIZE_T_FMT, AP_MAX_LIMIT_XML_BODY);
return NULL;
}
--
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]
