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/05/28 06:04:30 UTC
Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55
to 2.2.15
Hi William,
Refer to your words, so it's a bug in the bucket brigade mechanism? Should I
report it to the Apache bug system?
The two buckets are processed in the ap_core_output_filter(), and in the
case of EOS bucket (APR_BUCKET_IS_EOS is true)
That's why, the specific two buckets aren't sent out anymore..?!
Thank
Best regards,
honercek
On Fri, May 28, 2010 at 11:54 AM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:
> On 5/27/2010 10:44 PM, Chen Chien-Yu wrote:
> > Hi,
> >
> > I'm not familiar with the bucket, brigade at all.
> > It seems that the chunk will be sent via bucket brigade.
> > I found the stuck happen when the length of the bucket is "0" and the
> > next length of the bucket is "5" (0\r\n\r\n, is this the last chunk?).
> >
> > Why isn't the last chunk inserted in the bucket with web data?
> > Why the last two buckets with zero and five length aren't sent out?
>
> Most likely whatever appended a 5 byte bucket at the end forgot to pay
> attention to the EOS bucket that marked the end of the stream.
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
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 William,
I've ever mentioned if I comment out the "Listen 443" and leave only the
"Listen 80", the client can get the page without problem via HTTP. (In this
successful case, I also see the two 0 and 5 length bucket, don't know why
they are sent out even reach the EOS)
The problem only exists via HTTP when the "Listen 443" and "Listen 80"
coexist.
Browser is always fine in both case if I use HTTPS.
As the questions you said, I have to see what the answer are..but not sure
if I can figure them out.
Thanks
Best regards,
honercek
On Fri, May 28, 2010 at 12:14 PM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:
> On 5/27/2010 11:04 PM, Chen Chien-Yu wrote:
> > Hi William,
> >
> > Refer to your words, so it's a bug in the bucket brigade mechanism?
> > Should I report it to the Apache bug system?
> > The two buckets are processed in the ap_core_output_filter(), and in the
> > case of EOS bucket (APR_BUCKET_IS_EOS is true)
> > That's why, the specific two buckets aren't sent out anymore..?!
>
> There is no bug in the core, when EOS is hit, that's it.
>
> What module creates this missing 5 byte bucket? Was it a 0 len chunk
> header?
> If that never hits the wire, it sounds like it could be a bug, but I've
> seen
> no other reports of similar buggy behavior in 2.2.15, so I tend to suspect
> a
> module, and most likely an external one.
>
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?
>>>
>>
>>
>
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,
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 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 "William A. Rowe Jr." <wr...@rowe-clan.net>.
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?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
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 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?
Thanks
Best regards,
honercek
On Fri, May 28, 2010 at 4:02 PM, Chen Chien-Yu <ho...@gmail.com> wrote:
> Hi William,
>
> This is the place I found the 0 and 5 length bucket, cgi_read_stdout() in
> cgi_bucket_read() in mod_cgi.c which is the function for reading the data
> from the CGI bucket. So can I say that mod_cgi is the module my Apache uses
> instead of the mod_cgid. (And I didn't see the mod_cgid through "httpd -l"
> command)
>
> Is the problem possible in the CGI or mod_cgi, just like the prediction I
> did in the former post?
>
> Thanks
>
> Best regards,
> honercek
>
>
> On Fri, May 28, 2010 at 12:14 PM, William A. Rowe Jr. <wrowe@rowe-clan.net
> > wrote:
>
>> On 5/27/2010 11:04 PM, Chen Chien-Yu wrote:
>> > Hi William,
>> >
>> > Refer to your words, so it's a bug in the bucket brigade mechanism?
>> > Should I report it to the Apache bug system?
>> > The two buckets are processed in the ap_core_output_filter(), and in the
>> > case of EOS bucket (APR_BUCKET_IS_EOS is true)
>> > That's why, the specific two buckets aren't sent out anymore..?!
>>
>> There is no bug in the core, when EOS is hit, that's it.
>>
>> What module creates this missing 5 byte bucket? Was it a 0 len chunk
>> header?
>> If that never hits the wire, it sounds like it could be a bug, but I've
>> seen
>> no other reports of similar buggy behavior in 2.2.15, so I tend to suspect
>> a
>> module, and most likely an external one.
>>
>
>
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 William,
This is the place I found the 0 and 5 length bucket, cgi_read_stdout() in
cgi_bucket_read() in mod_cgi.c which is the function for reading the data
from the CGI bucket. So can I say that mod_cgi is the module my Apache uses
instead of the mod_cgid. (And I didn't see the mod_cgid through "httpd -l"
command)
Is the problem possible in the CGI or mod_cgi, just like the prediction I
did in the former post?
Thanks
Best regards,
honercek
On Fri, May 28, 2010 at 12:14 PM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:
> On 5/27/2010 11:04 PM, Chen Chien-Yu wrote:
> > Hi William,
> >
> > Refer to your words, so it's a bug in the bucket brigade mechanism?
> > Should I report it to the Apache bug system?
> > The two buckets are processed in the ap_core_output_filter(), and in the
> > case of EOS bucket (APR_BUCKET_IS_EOS is true)
> > That's why, the specific two buckets aren't sent out anymore..?!
>
> There is no bug in the core, when EOS is hit, that's it.
>
> What module creates this missing 5 byte bucket? Was it a 0 len chunk
> header?
> If that never hits the wire, it sounds like it could be a bug, but I've
> seen
> no other reports of similar buggy behavior in 2.2.15, so I tend to suspect
> a
> module, and most likely an external one.
>
Re: [users@httpd] Re: HTTP doesn't work after upgrading from 2.0.55
to 2.2.15
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/27/2010 11:04 PM, Chen Chien-Yu wrote:
> Hi William,
>
> Refer to your words, so it's a bug in the bucket brigade mechanism?
> Should I report it to the Apache bug system?
> The two buckets are processed in the ap_core_output_filter(), and in the
> case of EOS bucket (APR_BUCKET_IS_EOS is true)
> That's why, the specific two buckets aren't sent out anymore..?!
There is no bug in the core, when EOS is hit, that's it.
What module creates this missing 5 byte bucket? Was it a 0 len chunk header?
If that never hits the wire, it sounds like it could be a bug, but I've seen
no other reports of similar buggy behavior in 2.2.15, so I tend to suspect a
module, and most likely an external one.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org