On Sat, Jun 13, 2015 at 6:51 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:
>
> any chance you can reproduce the problem with a slightly patched 2.4.14 to
> get additional log output around the suspect code?
>
> The patch would be
>
> Index: modules/http/http_filters.c
> ===================================================================
> --- modules/http/http_filters.c (revision 1685283)
> +++ modules/http/http_filters.c (working copy)
> @@ -514,6 +514,9 @@
> rv = parse_chunk_size(ctx, buffer, len,
>
> f->r->server->limit_req_fieldsize);
> if (rv != APR_SUCCESS) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r,
> APLOGNO(99999)
> + "Error parsing chunk size, buffer
> %*.*s, limit %d",
> + len, len, buffer,
> f->r->server->limit_req_fieldsize);
> if (rv != APR_ENOSPC) {
> http_error = HTTP_BAD_REQUEST;
> }Hmm, it seems that the backported patch in r1684515 is not the proposed/voted v5, where AH01590 would normally have been logged here. Bill, looks like v4 was applied instead... Attached is the diff on http_filter.c between the two patches. BTW, v5 does not address the regression encountered by Steffen either: space(s) between the chunk-size and the CRLF which are not allowed anymore. This is not really RFC compliant, but I guess we have to be lenient here... I did not look at pr12355.t and pr43738.t yet, however those passed in my tests, so it's probably something different. Jeff, any idea where these failures can come from? What do -v and the logs say?
http_filters.c-2.4.x-v5_vs_v4.patch
Description: application/download
