On Sat, Jun 13, 2015 at 1:35 PM, Steffen <i...@apachelounge.com> wrote:

>
> Done:
>
>
> [http:error] [pid 6440:tid 1160] (22)Invalid argument: [remote
> 127.0.0.1:81] AH99999: Error parsing chunk size, buffer 4c7     \r\n,
> limit 8190
> [proxy_http:error] [pid 6440:tid 1160] (20014)Internal error (specific
> information not available): [client ::1:62059] AH01110: error reading
> response, referer: http://localhost:8080/syshelp/
>
> [http:error] [pid 6440:tid 1172] (22)Invalid argument: [remote
> 127.0.0.1:81] AH99999: Error parsing chunk size, buffer 5a5     \r\n,
> limit 8190
> [proxy_http:error] [pid 6440:tid 1172] (20014)Internal error (specific
> information not available): [client ::1:62058] AH01110: error reading
> response, referer: http://localhost:8080/syshelp/
>
>
I imagine that this would be fixed by the patch below:

Index: modules/http/http_filters.c
===================================================================
--- modules/http/http_filters.c (revision 1685298)
+++ modules/http/http_filters.c (working copy)
@@ -71,6 +71,7 @@
         BODY_CHUNK, /* chunk expected */
         BODY_CHUNK_PART, /* chunk digits */
         BODY_CHUNK_EXT, /* chunk extension */
+        BODY_CHUNK_CR, /* got space, expect space or CR or LF */
         BODY_CHUNK_LF, /* got CR, expect LF after digits/extension */
         BODY_CHUNK_DATA, /* data constrained by chunked encoding */
         BODY_CHUNK_END, /* chunked data terminating CRLF */
@@ -134,6 +135,11 @@
             ctx->chunk_used = 0;
         }

+        if (c == ' ' && ctx->state == BODY_CHUNK_CR) {
+            i++;
+            continue;
+        }
+
         if (c == LF) {
             if (ctx->remaining) {
                 ctx->state = BODY_CHUNK_DATA;
@@ -165,6 +171,12 @@
         else if (ctx->state == BODY_CHUNK_PART) {
             int xvalue;

+            if (c == ' ') {
+                ctx->state = BODY_CHUNK_CR;
+                i++;
+                continue;
+            }
+
             /* ignore leading zeros */
             if (!ctx->remaining && c == '0') {
                 i++;

Those that know the original patch would presumably have a better way to
code this.

I recall that httpd 1.3 generally added whitespace after the chunk size as
an optimization (pre-allocating space in BUFF for the largest possible
chunk size I guess).  Is it appropriate to allow whitespace both before and
after?  The patch above only allows it after.



>
> On Saturday 13/06/2015 at 18:51, Rainer Jung  wrote:
>
>> Hi Steffen,
>>
>> 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;
>>                                                    }
>>
>> It will *not* fix the problem but should give us enough additional info
>> to find out why it is happening.
>>
>> It would be great if you could patch your 2.4.14, rebuild and rerun the
>> Sambar test.
>>
>> Thanks a bunch!
>>
>> Rainer
>>
>> Am 13.06.2015 um 15:36 schrieb Steffen:
>>
>>>
>>> Debug 2.4.14 was already in my first post.
>>> The 2.4.13 (no error)  and 2.4.14 debug level error.log:
>>> Apache/2.4.13 (Win32)
>>> ================
>>> [Sat Jun 13 15:23:23.031198 2015] [authz_core:debug] [pid 9208:tid 1168]
>>> mod_authz_core.c(834): [client 127.0.0.1:54501] AH01628: authorization
>>> result: granted (no directives)
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> mod_proxy.c(1157): [client 127.0.0.1:54501] AH01143: Running scheme http
>>> handler (attempt 0)
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2145): AH00942: HTTP: has acquired connection for
>>> (127.0.0.1)
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2199): [client 127.0.0.1:54501] AH00944: connecting
>>> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2408): [client 127.0.0.1:54501] AH00947: connected
>>> /sysadmin/ to 127.0.0.1:81
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2782): AH02824: HTTP: connection established with
>>> 127.0.0.1:81 (127.0.0.1)
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
>>> (127.0.0.1)
>>> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
>>> proxy_util.c(2160): AH00943: http: has released connection for
>>> (127.0.0.1)
>>> Apache/2.4.14 (Win32)
>>> =================
>>> [Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152]
>>> mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization
>>> result: granted (no directives)
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http
>>> handler (attempt 0)
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2145): AH00942: HTTP: has acquired connection for
>>> (127.0.0.1)
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting
>>> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected
>>> /sysadmin/ to 127.0.0.1:81
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2782): AH02824: HTTP: connection established with
>>> 127.0.0.1:81 (127.0.0.1)
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
>>> (127.0.0.1)
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152]
>>> (20014)Internal error (specific information not available): [client
>>> 127.0.0.1:54430] AH01110: error reading response
>>> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
>>> proxy_util.c(2160): AH00943: HTTP: has released connection for
>>> (127.0.0.1)
>>> *From:* Jeff Trawick <mailto:traw...@gmail.com>
>>> *Sent:* Saturday, June 13, 2015 3:14 PM
>>> *Newsgroups:* gmane.comp.apache.devel
>>> *To:* Apache HTTP Server Development List <mailto:dev@httpd.apache.org>
>>> *Subject:* Re: [VOTE] Release Apache httpd 2.4.14 as GA
>>> On Sat, Jun 13, 2015 at 8:31 AM, Steffen <i...@apachelounge.com
>>> <mailto:i...@apachelounge.com>> wrote:
>>>
>>>          Tested with 2.4.13 tarball, then no error.
>>>
>>> Wow...
>>> Is anything written to the error log when you try proxy to the Sambar
>>> server?  If my guess about the related code is correct, you'll need
>>> LogLevel Info (or debug or trace) to see all the relevant messages.
>>>
>>>
>>>          -----Original Message----- From: Steffen
>>>          Sent: Saturday, June 13, 2015 1:33 PM Newsgroups:
>>>          gmane.comp.apache.devel
>>>          To: dev@httpd.apache.org <mailto:dev@httpd.apache.org>
>>>          Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
>>>
>>>
>>>          Regression: All works fine except a Proxy Pass  to Sambar
>>> server, was
>>>          working ok with 2.4.12.
>>>
>>>          ProxyPasses to other servers the Sambar works fine.
>>>
>>>          ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
>>>          ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
>>>
>>>          Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110:
>>> error
>>>          reading
>>>          response :
>>>
>>>          [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid
>>> 5684:tid 1128]
>>>          mod_authz_core.c(834): [client ::1:51072] AH01628:
>>> authorization result:
>>>          granted (no directives)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme
>>> http
>>>          handler
>>>          (attempt 0)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2145): AH00942: HTTP: has acquired connection for
>>>          (127.0.0.1)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2199): [client ::1:51072] AH00944: connecting
>>>      http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81 <http://127.0.0.1:81>
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2408): [client ::1:51072] AH00947: connected
>>> /sysadmin/ to
>>>          127.0.0.1:81 <http://127.0.0.1:81>
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2782): AH02824: HTTP: connection established with
>>>          127.0.0.1:81 <http://127.0.0.1:81>
>>>          (127.0.0.1)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2936): AH00962: HTTP: connection complete to
>>>          127.0.0.1:81 <http://127.0.0.1:81>
>>>          (127.0.0.1)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid
>>> 5684:tid 1128]
>>>          (20014)Internal error (specific information not available):
>>> [client
>>>          ::1:51072] AH01110: error reading response
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2160): AH00943: HTTP: has released connection for
>>>          (127.0.0.1)
>>>          [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid
>>> 1128]
>>>          proxy_util.c(2878): [remote 127.0.0.1:81 <http://127.0.0.1:81>]
>>>          AH02642: proxy: connection
>>>          shutdown
>>>
>>>
>>>
>>>          -----Original Message----- From: Jim Jagielski
>>>          Sent: Thursday, June 11, 2015 4:08 PM Newsgroups:
>>>          gmane.comp.apache.devel
>>>          To: httpd
>>>          Subject: [VOTE] Release Apache httpd 2.4.14 as GA
>>>
>>>          The pre-release test tarballs for Apache httpd 2.4.14 can be
>>> found
>>>          at the usual place:
>>>
>>>      http://httpd.apache.org/dev/dist/
>>>
>>>          I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>>
>>>          [ ] +1: Good to go
>>>          [ ] +0: meh
>>>          [ ] -1: Danger Will Robinson. And why.
>>>
>>>          Vote will last the normal 72 hrs.
>>>
>>>          NOTE: The *-deps are only there for convenience.
>>>
>>>          Thx!
>>>
>>>
>>>
>>> --
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>>>
>>
>> --
>> kippdata
>> informationstechnologie GmbH   Tel: 0228 98549 -0
>> Bornheimer Str. 33a            Fax: 0228 98549 -50
>> 53111 Bonn http://www.kippdata.de
>>
>> HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
>> Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
>>
>
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Reply via email to