You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Chen Chien-Yu <ho...@gmail.com> on 2010/06/01 10:25:25 UTC
Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55
to 2.2.15
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 <ho...@gmail.com> 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<http://mail-archives.apache.org/mod_mbox/httpd-users/201005.mbox/%3CAANLkTikTxKb8CV-ezRKfmaN0GZS4c3-Mw7V8kN1vYW51@mail.gmail.com%3E>.
> 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. <wr...@rowe-clan.net>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?
>>
>
>
Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55
to 2.2.15
Posted by Chen Chien-Yu <ho...@gmail.com>.
Hi,
First, I'd like to appreciate the helps from William and Jeff.
This is the mail I posted in APR mail list.
http://mail-archives.apache.org/mod_mbox/apr-dev/201006.mbox/ajax/%3cAANLkTilutiMLujySja8pdj7A16TI_gw6lU-E9U6I5oR2@mail.gmail.com%3e
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
I've been suffering from a problem for more than 1 week. The client will get
stuck when reading a page from Apache, it just waits for the zero-chunk
being sent from the Apache.
This post (
http://mail-archives.apache.org/mod_mbox/httpd-users/201005.mbox/%3CAANLkTinKrR60LOYct3eYtmCLwZAvL9OR3e8pWGOY72_K@mail.gmail.com%3E
)
describes the problem I met.
After some debugging and analyses (
http://mail-archives.apache.org/mod_mbox/httpd-users/201006.mbox/%3cAANLkTinwenme6xwGtPokzCMHhK5sHKAaFcVFAQRlWU0e@mail.gmail.com%3e
),
it seems the problem is caused by the APR library when processing the
bucket reading, an infinite loop?!
Then I found a post in this mail list with similar symptom as mine (
http://mail-archives.apache.org/mod_mbox/apr-dev/200704.mbox/%3C20070425010624.GA46804@zeus.kimaker.com%3E
),
and another discussion that might be related to my problem (
http://mail-archives.apache.org/mod_mbox/apr-dev/200405.mbox/%3c20040507002929.GA19761@manyfish.co.uk%3e
).
But the post about "blocking bucket reads on non-blocking sockets" was in
2004, it's 6 years ago.
The Apache version I'm using is 2.2.15, the newest stable version, I don't
think the bug fix wouldn't include in the version.
I've tested the fix "Ryan Phillips" posted in (
http://mail-archives.apache.org/mod_mbox/apr-dev/200704.mbox/%3C20070425010624.GA46804@zeus.kimaker.com%3E).
It did work for my case.
But I'm not sure if it's right or not..
Index: sockopt.c
===================================================================
--- sockopt.c (revision 532161)
+++ sockopt.c (working copy)
@@ -102,7 +102,7 @@
/* must disable the incomplete read support if we disable
* a timeout
*/
- if (t <= 0) {
+ if (t < 0) {
sock->options &= ~APR_INCOMPLETE_READ;
}
sock->timeout = t;
Thanks
Best regards,
honercek
On Wed, Jun 2, 2010 at 9:25 AM, Chen Chien-Yu <ho...@gmail.com> wrote:
> Hi All,
>
> I am sure the problem is irrelevant to the CGI and mod_CGI. Because I try
> to load a image file, the result is the same.
> And I forget to say one thing, the platform I'm using is a PowerPC
> architecture in an embedded system, so the apache is cross-compiled.
>
> I guess it might be the cause, and may be located in APR or APR-util?
>
> Anyway, that's really a tough issue for me...
>
> Thanks
>
>
> On Tue, Jun 1, 2010 at 4:25 PM, Chen Chien-Yu <ho...@gmail.com> wrote:
>
>> 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 <ho...@gmail.com>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<http://mail-archives.apache.org/mod_mbox/httpd-users/201005.mbox/%3CAANLkTikTxKb8CV-ezRKfmaN0GZS4c3-Mw7V8kN1vYW51@mail.gmail.com%3E>.
>>> 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. <
>>> wrowe@rowe-clan.net> 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?
>>>>
>>>
>>>
>>
>
Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55
to 2.2.15
Posted by Chen Chien-Yu <ho...@gmail.com>.
Hi All,
I am sure the problem is irrelevant to the CGI and mod_CGI. Because I try to
load a image file, the result is the same.
And I forget to say one thing, the platform I'm using is a PowerPC
architecture in an embedded system, so the apache is cross-compiled.
I guess it might be the cause, and may be located in APR or APR-util?
Anyway, that's really a tough issue for me...
Thanks
On Tue, Jun 1, 2010 at 4:25 PM, Chen Chien-Yu <ho...@gmail.com> wrote:
> 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 <ho...@gmail.com> 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<http://mail-archives.apache.org/mod_mbox/httpd-users/201005.mbox/%3CAANLkTikTxKb8CV-ezRKfmaN0GZS4c3-Mw7V8kN1vYW51@mail.gmail.com%3E>.
>> 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. <wrowe@rowe-clan.net
>> > 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?
>>>
>>
>>
>