Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 45177 invoked from network); 1 Jun 2010 08:26:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jun 2010 08:26:02 -0000 Received: (qmail 77155 invoked by uid 500); 1 Jun 2010 08:25:58 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 76838 invoked by uid 500); 1 Jun 2010 08:25:54 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 76830 invoked by uid 99); 1 Jun 2010 08:25:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 08:25:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of honercek@gmail.com designates 74.125.83.45 as permitted sender) Received: from [74.125.83.45] (HELO mail-gw0-f45.google.com) (74.125.83.45) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 08:25:46 +0000 Received: by gwb11 with SMTP id 11so2954090gwb.18 for ; Tue, 01 Jun 2010 01:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=LJzaKR6nf49MRL+VCpL5PawkxCyyViz5T+GrKMuwc+4=; b=QqaxTHnhaLj5iKHO3+XcgsuUNrLFloS6YoNiB94ALDghsqyQatmrBBF1yiPDAXOc6e DRk1ICQAYHA1LHFwdM2pCufzdXn3KG4YOmy2HPNb2ejxrbNaIXTtNlxhtpjji8/GgBD+ iZglGOfj4BQ1xNys7JyBLozTi02IUCAEy50so= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eXsnPhjtiiY7ppUuwgsaWINkyBLoXip7j2Aw2aq6TVSHWphakSQ59fSD0/emsPHIeM VKWFlfHt5QX/yAKqJgRI2pcY1bupbzBYYB5pSOQJrS1cP6kRNeXthWey3UCS42nedQSS O7stiniV2xfGB6f7PmEHed28wLAUB2hb3RYiU= MIME-Version: 1.0 Received: by 10.151.72.5 with SMTP id z5mr6020950ybk.235.1275380725366; Tue, 01 Jun 2010 01:25:25 -0700 (PDT) Received: by 10.151.146.16 with HTTP; Tue, 1 Jun 2010 01:25:25 -0700 (PDT) In-Reply-To: References: <4BFF3E5A.30706@rowe-clan.net> <4BFF431B.2090607@rowe-clan.net> <4BFFBDFD.1020606@rowe-clan.net> Date: Tue, 1 Jun 2010 16:25:25 +0800 Message-ID: From: Chen Chien-Yu To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=000e0cd696fa16bfe30487f3b76e X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55 to 2.2.15 --000e0cd696fa16bfe30487f3b76e Content-Type: text/plain; charset=UTF-8 Hi All, After using the strace tools, there's a new find. It will stop at the function call read().... A infinite loop happens in server/core_filters.c ap_core_input_filter(). if (mode == AP_MODE_EATCRLF) { apr_bucket *e; const char *c; while (1) { if (APR_BRIGADE_EMPTY(ctx->b)) { return APR_EOF; } e = APR_BRIGADE_FIRST(ctx->b); rv = apr_bucket_read(e, &str, &len, APR_NONBLOCK_READ); *<--------------- I guess this is the place gets stuck...* if (rv != APR_SUCCESS) { return rv; *<---- successful case will exit via this place with the value of rv = 11. (APR_ENOSOCKET ??)* } c = str; while (c < str + len) { if (*c == APR_ASCII_LF) c++; else if (*c == APR_ASCII_CR && *(c + 1) == APR_ASCII_LF) c += 2; else return APR_SUCCESS; } /* If we reach here, we were a bucket just full of CRLFs, so * just toss the bucket. */ /* FIXME: Is this the right thing to do in the core? */ apr_bucket_delete(e); } I don't know why it's stuck here, and does it relate to the zero-chunk packet that doesn't see in the client? Thanks Best regards, honercek On Mon, May 31, 2010 at 8:14 AM, Chen Chien-Yu wrote: > Hi William, > > I'm sorry to confuse you. > Please let me reorganize the problem and my observations. > > Client ---- HTTP ---- Apache ---- Mod-CGI ---- xxx.cgi ---- login.html > > > A client(browser) access the URI, http://xxx.xxx.xxx/xxx.cgi which is > located on the Apache 2.2.15, but finally what it got was only the content > of page and lack of the last chunk, which made the browser stuck and > loading continually. > > xxx.cgi is written with the GNU library looks like this. > It will read the file login.html and put it on the network stream to the > client. > I've also tried to return a string only "Hello" instead of the file > content, the result is the same stuck. > > If the directive HTTPS exists (Listen 443), the HTTP will not work > correctly(Case A). But if I comment out the directives HTTPS, the HTTP will > work without any problem(Case B). So I compared them by adding some debug > messages in Apache. > There is another case that is workable as well, even the HTTP and HTTPS > exist at the same time.(disable the KeepAlive mechanism, but it a must > option for us in the performance point of view) > > All the output filters are the built in ones, I didn't insert any one I > write. (There are the filters I found, byterange, content length, > http_header, http_outerror, core) > > > ============================================================================================ > > Client ---- HTTP ---- Apache ---- Mod-CGI ---- xxx.cgi ---- login.html > > In Mod-CGI, there's a function called cgi_bucket_read(). It's a read method > of CGI bucket: polls on stdout of the child. I found it read 806 bytes via a > function call cgi_read_stdout() from stdout followed by a 0 byte read. > > Then in Apache core filter, a function called ap_core_output_filter(), in > the case of EOS, the function apr_bucket_read() inside it reads two times in > a row, a 0 byte followed by a 5 bytes(0\r\n\r\n). Seems that, the 5 bytes > bucket is the one the client expect. > > Until now, there's no difference between Case A and Case B. > > After this, I found the successful one(Case B) will flush out a 5 bytes > bucket in the core filter. I have no idea who triggers this event. But > nothing happens in Case A. > > Thanks > > Best regards, > honercek > > > On Fri, May 28, 2010 at 8:58 PM, William A. Rowe Jr. wrote: > >> On 5/28/2010 3:08 AM, Chen Chien-Yu wrote: >> > Hi William, >> > >> > I gave you the incorrect information in the previous post. >> > >> > cgi_read_stdout() in cgi_bucket_read() in mod_cgi.c, the data length is >> > 806 followed by 0. (Not the 0 and 5 buckets) >> > then ap_core_output_filter() found a 0 length bucket, and appended a >> > last-chunk bucket? >> >> What you describe sounds like correct HTTP behavior. The last-chunk >> bucket is being correctly transmitted after the 806 byte bucket? >> >> I'm losing track of what the exact problem is. >> >> Also do you insert any additional filters for the output of this filter? >> > > --000e0cd696fa16bfe30487f3b76e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All,

After using the strace tools, there's a new = find. It will stop at the function call read()....
A infinite loo= p happens in server/core_filters.c ap_core_input_filter().


=C2=A0=C2=A0 =C2=A0if (mode =3D=3D AP_MODE_E= ATCRLF) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0apr_bucket *e;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0const char *c;

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0while (1) {
=C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0if (APR_BRIGADE_EMPTY(ctx->b)) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return AP= R_EOF;
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0}

=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e =3D APR_BRIGADE_FIRST(ctx->b);

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rv = =3D apr_bucket_read(e, &str, &len, APR_NONBLOCK_READ); <-----= ---------- I guess this is the place gets stuck...

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (rv != =3D APR_SUCCESS) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0return rv; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<---- successful case will exit via this place with the val= ue of rv =3D 11. (APR_ENOSOCKET ??)
=C2=A0=C2= =A0 =C2=A0}

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0c =3D str;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0while (c < str + len) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0if (*c =3D=3D APR_ASCII_LF)
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= c++;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0else if (*c =3D=3D APR_ASCII_CR && *(c + 1) =3D=3D APR_ASCII_LF)=
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0c +=3D 2;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0else
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return APR_SUCCESS;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

<= div>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If we reach here, we = were a bucket just full of CRLFs, so
=C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * just toss the bucket. */
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* FIXME: Is this the right thing to do in t= he core? */
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apr_bucket_delete(e);
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}

I don&= #39;t know why it's stuck here, and does it relate to the zero-chunk pa= cket that doesn't see in the client?

Thanks

Best regards,
hone= rcek

On Mon, May 31, 2010 at 8:14 = AM, Chen Chien-Yu <honercek@gmail.com> wrote:
Hi William,

I'm s= orry to confuse you.
Please let me reorganize the problem and my = observations.

Client ---- HTTP ---- Apache ---- Mod-CGI ---- xxx.cgi = ---- login.html
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0

A client(browser) access the URI, http://xxx.xxx.xxx/xxx.c= gi which is located on the Apache 2.2.15, but finally what it got was o= nly the content of page and lack of the last chunk, which made the browser = stuck and loading=C2=A0continually.

xxx.cgi is written with the GNU library looks like this. It will read the file login.html and put it on the networ= k stream to the client.
I've also tried to return a string only "Hello" instead = of the file content, the result is the same stuck.

If the directive HTTPS exists (Listen 443), the HTTP will not work corr= ectly(Case A). But if I comment out the directives HTTPS, the HTTP will wor= k without any problem(Case B). So I compared them by adding some debug mess= ages in Apache.
There is another case that is workable as well, even the HTTP and HTTP= S exist at the same time.(disable the KeepAlive mechanism, but it a must op= tion for us in the performance point of view)

All the output filters are the built in ones, I didn't insert any one I= write. (There are the filters I found, byterange, content length, http_hea= der, http_outerror, core)

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Client ---- HTTP ---- Apache ---- Mod-CGI ---- xxx.cgi = ---- login.html

In Mod-CGI, there's a function= called=C2=A0cgi_bucket_read(). It's a read method of CGI bucket: polls= on stdout of the child. I found it read 806 bytes via a function call cgi_= read_stdout() from stdout followed by a 0 byte read.

Then in Apache core filter, a function called=C2=A0ap_c= ore_output_filter(), in the case of EOS, the function=C2=A0apr_bucket_read(= ) inside it reads two times in a row, a 0 byte followed by a 5 bytes(0\r\n\= r\n). Seems that, the 5 bytes bucket is the one the client expect.

Until now, there's no difference between Case A and= Case B.

After this, I found the successful one(Ca= se B) will flush out a 5 bytes bucket in the core filter. I have no idea wh= o triggers this event. But nothing happens in Case A.

Thanks

Best regards,
honercek


On Fri, May 28, 2010 at 8:58 PM, William A. Rowe J= r. <wrowe@rowe-clan.net> wrote:
On 5/28/2010 3:08 AM, Chen Chien-Yu wro= te:
> Hi William,
>
> I gave you the incorrect information in the previous post.<= br> >
> cgi_read_stdout() in cgi_bucket_read() in mod_cgi.c, the data length i= s
> 806 followed by 0. (Not the 0 and 5 buckets)
> then ap_core_output_filter() found a 0 length bucket, and appended a > last-chunk bucket?

What you describe sounds like correct HTTP behavior. =C2=A0The last-c= hunk
bucket is being correctly transmitted after the 806 byte bucket?

I'm losing track of what the exact problem is.

Also do you insert any additional filters for the output of this filter?


--000e0cd696fa16bfe30487f3b76e--