You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Symptom: when uploading files to a backend using mod_proxy_ajp or mod_wl, the request body (file contents) can get truncated. The problem is reproducible when using
SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecRequestBodyLimitAction ProcessPartial
and setting SecRequestBodyNoFilesLimit, SecRequestBodyLimit and SecRequestBodyInMemoryLimit to a value smaller than the file size. In addition I could only easily reproduce the problem when not including any CRS rules. I can provide a full config plus simple test app if needed.
The problem happens when the rquest body limit is reached and partial body processing is active. If bytes are overflowing to disk, then the last read attempt from the mod_security input filter will return 0 bytes and remove the input filter from the filter chain. Following retrievals from the filter chain will correctly return the remaining bytes.
But mod_wl and mod_prox_ajp react on a 0 byte return from the request body read by ending the request body transfer to the backend. For mod_wl the reason is not clear (closed source), but the result is a "503 Service Unavailable" error. For mod_proxy_ajp the reason is, that a zero byte AJP request body packet indicates the end of the body in the AJP protocol, so the backend doesn't pull the remaining parts of the body and instead starts sending the response.
I will create a simple PR. The patch tracks, whether the mod_security input filter actually returns data or not. In case it does not return data and removes itself from the chain, it will delegate to the remaing filter chain instead of just returning APR_SUCCESS.
Regards,
Rainer
The text was updated successfully, but these errors were encountered:
… the last read and if not, delegate to the remaining filter chain.
Without that, ProcessPartial for the request body breaks forwarding
of uploaded files using mod_proxy_ajp and mod_wl.
See issue #2091.
Version: 2.9.3
Symptom: when uploading files to a backend using mod_proxy_ajp or mod_wl, the request body (file contents) can get truncated. The problem is reproducible when using
SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecRequestBodyLimitAction ProcessPartial
and setting SecRequestBodyNoFilesLimit, SecRequestBodyLimit and SecRequestBodyInMemoryLimit to a value smaller than the file size. In addition I could only easily reproduce the problem when not including any CRS rules. I can provide a full config plus simple test app if needed.
The problem happens when the rquest body limit is reached and partial body processing is active. If bytes are overflowing to disk, then the last read attempt from the mod_security input filter will return 0 bytes and remove the input filter from the filter chain. Following retrievals from the filter chain will correctly return the remaining bytes.
But mod_wl and mod_prox_ajp react on a 0 byte return from the request body read by ending the request body transfer to the backend. For mod_wl the reason is not clear (closed source), but the result is a "503 Service Unavailable" error. For mod_proxy_ajp the reason is, that a zero byte AJP request body packet indicates the end of the body in the AJP protocol, so the backend doesn't pull the remaining parts of the body and instead starts sending the response.
I will create a simple PR. The patch tracks, whether the mod_security input filter actually returns data or not. In case it does not return data and removes itself from the chain, it will delegate to the remaing filter chain instead of just returning APR_SUCCESS.
Regards,
Rainer
The text was updated successfully, but these errors were encountered: