RE: Releasing 2.0.42
> From: Kean Johnston [mailto:[EMAIL PROTECTED]] > Sent: 24 September 2002 03:29 > Just as a matter of interest, which version or what date did the > APR/APU snapshot come from? I recently made some changes to APR > for SCO OpenServer that'd be great if they went out with 2.0.42. Your changes were committed after the T&R of 2.0.42. Expect them to be in the next release. Sander
Re: 2.0 mod_dav thinks / isn't a collection, mod_dir gets in the way
* Wilfredo Sánchez wrote:
>My guess is that mod_dir is poking in here and returning index.html
> for /. I do have DirectoryIndex set in the main server config, but I
> didn't have this problem in 1.3. Is this new behavior? There's no
> comment in the docs about how to turn off DirectoryIndex for a
> location (eg. for a virtual host).
It can't be turned off. you may set it it to a file that is never found.
>Commenting out the DirectoryIndex altogether didn't fix the
>problem,
> but disabling the loading of mod_dir does. Unfortunate, since I do
> want mod_dir sometimes.
>
>Any ideas?
The problem should be fixed in 2.0.42.
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
RE: Releasing 2.0.42
Just as a matter of interest, which version or what date did the APR/APU snapshot come from? I recently made some changes to APR for SCO OpenServer that'd be great if they went out with 2.0.42. Kean. > I'm now confident that 2.0.42 is stable.
2.0 mod_dav thinks / isn't a collection, mod_dir gets in the way
I've switched my home server from a Linux box running httpd 1.3 to my Mac running httpd 2.0. For my each site I host, I've got two virtual hosts, one which is the public server and another which is DAV-enabled for editing. I usually just mount the DAV server using the DAV filesystem in OS X and edit that way. I ran into a problem after the switch, though, and the clients can't mount the server any more. I poked around a bit using tcpflow and bugged the owner of webdavfs at Apple, and the problem seems to be that httpd is telling the client that the URI / is not a collection, so the mount fails. I'm seeing behavior using Goliath which show it's getting confused as well; it will show me index.html but no subdirectories. My guess is that mod_dir is poking in here and returning index.html for /. I do have DirectoryIndex set in the main server config, but I didn't have this problem in 1.3. Is this new behavior? There's no comment in the docs about how to turn off DirectoryIndex for a location (eg. for a virtual host). Commenting out the DirectoryIndex altogether didn't fix the problem, but disabling the loading of mod_dir does. Unfortunate, since I do want mod_dir sometimes. Any ideas? -wsv
APXS
>From the code in apxs; when one does an
apxs -ia mod_foobar.so
I get the error from below. Which can be easily fixed by using
the -n flag as advised.
Now naively this seems to be because by '1' we eat too much from the back
of the string (i.e. the full '.so') while we expect something there later
(near 2).
Now is this a simple bug ?
Or is this something more subtle; as some platforms need/have more complex
extension requirements perhaps for their SOs ? And would 'fixing' this
break 15 other things ?
if ($name eq 'unknown') {
$name = '';
my $base = $f;
1-> $base =~ s|\.[^.]+$||;
cut..
if ($name eq '') {
if ($base =~ m|.*mod_([a-zA-Z0-9_]+)\..+|) {
2---
$name = "$1";
$filename = $base;
$filename =~ s|^.+/||;
$filename =~ s|^.+\\|| if ($^O eq "MSWin32");
}
}
if ($name eq '') {
print STDERR "apxs:Error: Sorry, cannot determine bootstrap symbol
name.\n";
print STDERR "apxs:Error: Please specify one with option `-n'.\n";
exit(1);
}
}
Any advice - specifically from our portable crowd ?
Dw.
Re: graceful?
Cliff Woolley wrote: > > Has anybody torture tested graceful restarts lately? I only ask because > we just got a PR that gave me "that sinking feeling". Maybe not a real > problem, but just figured I'd ask. They work on daedalus with prefork. But that's typically just once a night - not sure if that qualifies as a torture test. Greg
Re: Releasing 2.0.42
[EMAIL PROTECTED] wrote: > > Sander Striker wrote: > > > > Hi, > > > > Done enough testing to say: > > > > +1 for GA > > I reserve my judgement until it has run longer without problems on daedalus. I'm now confident that 2.0.42 is stable. Greg
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Matthieu Estrade wrote:
In a previous note you explained:
> on the file not cached because the MaxStreamingBuffer error, the code above never
>detect a EOS bucket, so, it return a size to the following code:
> if (!all_bucket_here){
> if (unresolved_length || size > MaxStreamingBuffer)
> exit with MaxStreamingBuffer Error.
> }
If it entered into this chunk of code then the cache code either:
1) encountered a bucket with an unresolved length (like a socket bucket) or
2) the cumulative length of all buckets/brigades encountered so far was greater
then the value of MaxStreamingBuffer.
If the program goes into this branch of code it will remove the cache filter
from teh filter chain. This is why the cache code is not looking at any of
the subsequent brigades. Cache has already determined that it has no reason
to look at them.
If this is happening due to exceeding MaxStreamingBuffer, try setting the
value to something higher and see if it works for you. If it is encountering
a bucket with an unresolved length then there is nothing that can be done.
That type of bucket cannot be cached.
Proxy is working the way it should.
>
> Hi Paul,
>
> I know about mod_cache is only working on one brigade, but my problem is
> not here.
> My problem is i can't setup the filter cache_in_filter to be executed
> after mod_proxy pass his "last" brigade to the filter chain
> Actually, mod_cache_filter_in is executed only one time when mod_proxy
> have passed the "first" brigade to the output_filters.
> So the others brigade containing data are not available.
>
> so, have i to consider that cache_filter_in will have to be able to
> cache document in many times process,
> Or is it possible to think that the cache_filter could be placed when
> mod_proxy finished to pass the "last" brigade,
> reading all the brigade and cache it ?
>
> regards,
>
> Matthieu
>
> Paul J. Reder wrote:
>
>> Actually, the problem is in the fact that there is more than one
>> brigade and the cache code can't currently handle that.
>>
>> Proxy is working the way it is supposed to. This allows Apache
>> to process large responses without having to buffer the whole
>> thing inside Apache. Apache uses less memory, and the user starts
>> seeing results sooner. If proxy were to process all of the
>> brigades of a large response before the next filter were allowed
>> access, then proxy could potentially buffer a *huge* amount of
>> data.
>>
>> The answer is that the cache code currently only caches responses
>> that arrive in one brigade. Proxy isn't the problem.
>>
>> Matthieu Estrade wrote:
>>
>>> Hi graham,
>>>
>>> the problem is the filter is called between two ap_pass_brigade by
>>> the reverse proxy...
>>> like:
>>>
>>> proxy:
>>> get_brigade (data from backend)
>>> pass_brigade(pass data to outputfilter)
>>> cache_filter
>>> get_brigade(data from backend)
>>> pass_brigade(pass_data_to outputfilter)
>>>
>>> on one response by the backend server.
>>>
>>> regards,
>>> Matthieu
>>>
>>> Graham Leggett wrote:
>>>
Matthieu Estrade wrote:
> I agree with you about the proxy...
> Do you think it's possible to force the cache filter, be runned
> after all the proxy filters ?
The cache filter is supposed to run after all the filters for
maximum caching advantage.
Regards,
Graham
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Hi Paul, I know about mod_cache is only working on one brigade, but my problem is not here. My problem is i can't setup the filter cache_in_filter to be executed after mod_proxy pass his "last" brigade to the filter chain Actually, mod_cache_filter_in is executed only one time when mod_proxy have passed the "first" brigade to the output_filters. So the others brigade containing data are not available. so, have i to consider that cache_filter_in will have to be able to cache document in many times process, Or is it possible to think that the cache_filter could be placed when mod_proxy finished to pass the "last" brigade, reading all the brigade and cache it ? regards, Matthieu Paul J. Reder wrote: > Actually, the problem is in the fact that there is more than one > brigade and the cache code can't currently handle that. > > Proxy is working the way it is supposed to. This allows Apache > to process large responses without having to buffer the whole > thing inside Apache. Apache uses less memory, and the user starts > seeing results sooner. If proxy were to process all of the > brigades of a large response before the next filter were allowed > access, then proxy could potentially buffer a *huge* amount of > data. > > The answer is that the cache code currently only caches responses > that arrive in one brigade. Proxy isn't the problem. > > Matthieu Estrade wrote: > >> Hi graham, >> >> the problem is the filter is called between two ap_pass_brigade by >> the reverse proxy... >> like: >> >> proxy: >> get_brigade (data from backend) >> pass_brigade(pass data to outputfilter) >> cache_filter >> get_brigade(data from backend) >> pass_brigade(pass_data_to outputfilter) >> >> on one response by the backend server. >> >> regards, >> Matthieu >> >> Graham Leggett wrote: >> >>> Matthieu Estrade wrote: >>> I agree with you about the proxy... Do you think it's possible to force the cache filter, be runned after all the proxy filters ? >>> >>> >>> >>> >>> The cache filter is supposed to run after all the filters for >>> maximum caching advantage. >>> >>> Regards, >>> Graham >> >> >> >> >> >> >> > >
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Graham Leggett wrote: > Matthieu Estrade wrote: > >> I agree with you about the proxy... >> Do you think it's possible to force the cache filter, be runned after >> all the proxy filters ? > > > The cache filter is supposed to run after all the filters for maximum > caching advantage. > I disagree on this. the cache filter should be able to placed where the admin wants it. what the code should do is remember which filters where placed above the cache_input filter, and restore these filters on cache_output. this would allow people to have pages designed for a specific user, as well as caching most of it > Regards, > Graham
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Actually, the problem is in the fact that there is more than one brigade and the cache code can't currently handle that. Proxy is working the way it is supposed to. This allows Apache to process large responses without having to buffer the whole thing inside Apache. Apache uses less memory, and the user starts seeing results sooner. If proxy were to process all of the brigades of a large response before the next filter were allowed access, then proxy could potentially buffer a *huge* amount of data. The answer is that the cache code currently only caches responses that arrive in one brigade. Proxy isn't the problem. Matthieu Estrade wrote: > Hi graham, > > the problem is the filter is called between two ap_pass_brigade by the > reverse proxy... > like: > > proxy: > get_brigade (data from backend) > pass_brigade(pass data to outputfilter) > cache_filter > get_brigade(data from backend) > pass_brigade(pass_data_to outputfilter) > > on one response by the backend server. > > regards, > Matthieu > > Graham Leggett wrote: > >> Matthieu Estrade wrote: >> >>> I agree with you about the proxy... >>> Do you think it's possible to force the cache filter, be runned after >>> all the proxy filters ? >> >> >> >> The cache filter is supposed to run after all the filters for maximum >> caching advantage. >> >> Regards, >> Graham > > > > > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: Releasing 2.0.42
Looks good on NetWare, +1 Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, September 20, 2002 11:19:35 AM >>> Hi, Done enough testing to say: +1 for GA Sander
Re: graceful?
Cliff Woolley wrote: > > On Mon, 23 Sep 2002, Jim Jagielski wrote: > > > Not me lately... What's the # ? > > Oy... um, the last one? ;-] > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12033 > > Oh, and not to startle the 1.3.27 RM... I should have mentioned it's a 2.0 > PR. =] > I assumed it was 2.0 :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Hi graham, the problem is the filter is called between two ap_pass_brigade by the reverse proxy... like: proxy: get_brigade (data from backend) pass_brigade(pass data to outputfilter) cache_filter get_brigade(data from backend) pass_brigade(pass_data_to outputfilter) on one response by the backend server. regards, Matthieu Graham Leggett wrote: > Matthieu Estrade wrote: > >> I agree with you about the proxy... >> Do you think it's possible to force the cache filter, be runned after >> all the proxy filters ? > > > The cache filter is supposed to run after all the filters for maximum > caching advantage. > > Regards, > Graham
Re: [VOTE]: Where to place I/O logging
On Tue, 2002-09-24 at 00:08, Ian Holsman wrote: > This is why I want it in it's own module so people who don't want this > information won't have to suffer the penalty And that's what my last patch is all about :-) Bojan PS. Plus, it's disabled by default :-))
Re: graceful?
On Mon, 23 Sep 2002, Jim Jagielski wrote: > Not me lately... What's the # ? Oy... um, the last one? ;-] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12033 Oh, and not to startle the 1.3.27 RM... I should have mentioned it's a 2.0 PR. =] --Cliff
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Matthieu Estrade wrote: > I agree with you about the proxy... > Do you think it's possible to force the cache filter, be runned after > all the proxy filters ? The cache filter is supposed to run after all the filters for maximum caching advantage. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..."
Re: graceful?
Cliff Woolley wrote: > > > Has anybody torture tested graceful restarts lately? I only ask because > we just got a PR that gave me "that sinking feeling". Maybe not a real > problem, but just figured I'd ask. > Not me lately... What's the # ? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
graceful?
Has anybody torture tested graceful restarts lately? I only ask because we just got a PR that gave me "that sinking feeling". Maybe not a real problem, but just figured I'd ask. --Cliff
Re: Patch mod_proxy: mod_proxy + mod_cache problem
hi bill, I agree with you about the proxy... Do you think it's possible to force the cache filter, be runned after all the proxy filters ? Matthieu Bill Stoddard wrote: >>Hi again :) >> >>I did a patch modifiying mod_proxy to pass the entire data (response >>from backend server) to output_filter, unstead of brigade per brigade. >> >> >> >One comment (having not reviewed the patch): Proxy should stream bytes from >the backend server to the client as those bytes arrive. Proxy should not >require that the entire response from the backend be received before writing >to the client. > >Bill > > > > >
Re: [VOTE]: Where to place I/O logging
Jeff Trawick wrote: > Bojan Smojver <[EMAIL PROTECTED]> writes: > > >>Just so that I can put this one to rest (i.e. prepare the final patch >>accordingly), could you please vote: >>[ ] Put I/O logging on mod_log_config and have LogInputOutput flag >>[ ] Put I/O logging in a separate module, mod_logio > > > The logic you're talking about simply counts input and output bytes > and doesn't log actual data, right? it introduces 2 new log tags %I & %O. it counts the data by introducing 2 new filters into the food chain. from what I can see, these 2 filters will be run regardless of whether I have the tags in my log format line. This is why I want it in it's own module so people who don't want this information won't have to suffer the penalty > > The place these counts gets logged is in output controlled by > mod_log_config, right? >
Re: Patch mod_proxy: mod_proxy + mod_cache problem
Matthieu Estrade wrote: > I did a patch modifiying mod_proxy to pass the entire data (response > from backend server) to output_filter, unstead of brigade per brigade. AFAIK the problem stems from a limitation in mod_cache where it can only cache stuff in a single brigade at the moment. Proxy works correctly already - there is no such thing as "pass the entire data", because there is no way for proxy to know just how much data there is in advance, and there is no guarantee that data will all fit in memory at once. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..."
Re: [VOTE]: Where to place I/O logging
On Mon, 2002-09-23 at 22:20, Jeff Trawick wrote: > Bojan Smojver <[EMAIL PROTECTED]> writes: > > > Just so that I can put this one to rest (i.e. prepare the final patch > > accordingly), could you please vote: > > [ ] Put I/O logging on mod_log_config and have LogInputOutput flag > > [ ] Put I/O logging in a separate module, mod_logio > > The logic you're talking about simply counts input and output bytes > and doesn't log actual data, right? > > The place these counts gets logged is in output controlled by > mod_log_config, right? Option 1 is counting (the filter code) and logging in mod_log_config. Option 2 is counting in mod_logio (the patch I submitted today) and then logging in mod_log_config using optional function. Bojan
RE: Patch mod_proxy: mod_proxy + mod_cache problem
> Hi again :) > > I did a patch modifiying mod_proxy to pass the entire data (response > from backend server) to output_filter, unstead of brigade per brigade. > One comment (having not reviewed the patch): Proxy should stream bytes from the backend server to the client as those bytes arrive. Proxy should not require that the entire response from the backend be received before writing to the client. Bill
Patch mod_proxy: mod_proxy + mod_cache problem
Hi again :)
I did a patch modifiying mod_proxy to pass the entire data (response
from backend server) to output_filter, unstead of brigade per brigade.
it seems to work well...
Matthieu
Matthieu Estrade wrote:
>
> Hi again,
>
> the problem seems to be in the proxy.
>
> When proxy read the data and pass it to output filter, it do:
>
> while (ap_get_brigade){
>
> ap_pass_brigade(output_filter)
>
> }
>
> si if the data aren't read by only one brigade, the mod_cache can't work.
> because it will try to cache only the first brigade with a part of data.
>
> Do you think it's better to modify how proxy is passing data to the
> output_filter
> or to modify the way mod_cache is getting his data from bucket_brigade ?
>
> Matthieu
>
> Matthieu Estrade wrote:
>
>
? proxy_http.patch
Index: proxy_http.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.160
diff -u -r1.160 proxy_http.c
--- proxy_http.c22 Aug 2002 15:02:49 - 1.160
+++ proxy_http.c23 Sep 2002 11:58:44 -
@@ -679,6 +679,8 @@
char keepchar;
request_rec *rp;
apr_bucket *e;
+apr_bucket_brigade *send_to_client = apr_brigade_create(p, c->bucket_alloc);
+
int len, backasswards;
int received_continue = 1; /* flag to indicate if we should
* loop over response parsing logic
@@ -931,13 +933,8 @@
finish = TRUE;
}
-/* try send what we read */
-if (ap_pass_brigade(r->output_filters, bb) != APR_SUCCESS) {
-/* Ack! Phbtt! Die! User aborted! */
-p_conn->close = 1; /* this causes socket close below */
-finish = TRUE;
-}
-
+ APR_BRIGADE_CONCAT(send_to_client,bb);
+
/* make sure we always clean up after ourselves */
apr_brigade_cleanup(bb);
@@ -946,6 +943,14 @@
break;
}
}
+
+ /* try send what we read */
+ if (ap_pass_brigade(r->output_filters, send_to_client) != APR_SUCCESS) {
+ /* Ack! Phbtt! Die! User aborted! */
+ p_conn->close = 1; /* this causes socket close below */
+ }
+
+
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy: end body send");
Re: [VOTE]: Where to place I/O logging
Bojan Smojver <[EMAIL PROTECTED]> writes: > Just so that I can put this one to rest (i.e. prepare the final patch > accordingly), could you please vote: > [ ] Put I/O logging on mod_log_config and have LogInputOutput flag > [ ] Put I/O logging in a separate module, mod_logio The logic you're talking about simply counts input and output bytes and doesn't log actual data, right? The place these counts gets logged is in output controlled by mod_log_config, right? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: mod_proxy + mod_cache problem, loosing EOS bucket
Hi again,
the problem seems to be in the proxy.
When proxy read the data and pass it to output filter, it do:
while (ap_get_brigade){
ap_pass_brigade(output_filter)
}
si if the data aren't read by only one brigade, the mod_cache can't work.
because it will try to cache only the first brigade with a part of data.
Do you think it's better to modify how proxy is passing data to the
output_filter
or to modify the way mod_cache is getting his data from bucket_brigade ?
Matthieu
Matthieu Estrade wrote:
> Hi,
>
> i'am working on mod_cache and mod_mem_cache + mod_proxy
> i found a problem with EOS Bucket.
>
> mod_cache is inserting his cache_in filter in output_filter when he
> wants to insert data in the cache.
> when mod_cache is used with mod_proxy, the cache_in filter is called
> after mod_proxy call ap_pass_brigade in the
> ap_proxy_http_process_response, after received data from backend server.
>
> when i do test on a website, sometimes, i can see my file is not
> cached because length > MaxStreamingBuffer.
> when i put a debug on the MaxStreamingBuffer value, i always get 0
> even if i setup in my httpd.conf another value with
> CacheMaxStreamingBuffer.
> So maybe a first bug here.
>
> But the problem doesn't come from this bug.
>
> When i process my test, i can see that some files are not cached
> because of this error, so i put debug in the function calculating the
> length of data to be cached in mod_cache.
> And something really strange happen, strange for me, but maybe not for
> you
>
> what happen:
>
> APR_BRIGADE_FOR_EACH(e,in){
>
> look if bucket is eos, if yes, exit with all_bucket_here=1
> or: look if bucket is flush, if yes, exit with unresolved_length=1
> or: size += e->length;
>
> }
>
> on the file not cached because the MaxStreamingBuffer error, the code
> above never detect a EOS bucket, so, it return a size to the following
> code:
>
> if (!all_bucket_here){
> if (unresolved_length || size > MaxStreamingBuffer)
> exit with MaxStreamingBuffer Error.
> }
>
> Where it's really strange, is i put a debug in mod_proxy, when it
> receive the data from backend server, and before passing the brigade
> to the output_filter, i can detect a EOS Bucket.
> So, i have a EOS Bucket found in the brigade mod_proxy will pass to
> output_filter, and in the filter reading the same brigade in mod_cache
> (cache_in filter), i can't find this same EOS Bucket.
>
> if someone have an idea :)
> i will continue to search on that.
>
> Best regards,
>
> Estrade Matthieu
>
>
>
>
Re: cvs commit: httpd-2.0/docs/manual/platform ebcdic.xml index.xml ebcdic.html.en index.html.en
Joshua Slive <[EMAIL PROTECTED]> writes: > Jeff Trawick wrote: > > There probably does need to be an EBCDIC section describing minor > > issues with the core code and with standard modules (e.g., SSI files > > need to be in the native character set so that mod_include can parse > > them*). > > Anyone feel like taking that on? feel like? sure have time? I'll try. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
mod_proxy + mod_cache problem, loosing EOS bucket
Hi,
i'am working on mod_cache and mod_mem_cache + mod_proxy
i found a problem with EOS Bucket.
mod_cache is inserting his cache_in filter in output_filter when he
wants to insert data in the cache.
when mod_cache is used with mod_proxy, the cache_in filter is called
after mod_proxy call ap_pass_brigade in the
ap_proxy_http_process_response, after received data from backend server.
when i do test on a website, sometimes, i can see my file is not cached
because length > MaxStreamingBuffer.
when i put a debug on the MaxStreamingBuffer value, i always get 0 even
if i setup in my httpd.conf another value with CacheMaxStreamingBuffer.
So maybe a first bug here.
But the problem doesn't come from this bug.
When i process my test, i can see that some files are not cached because
of this error, so i put debug in the function calculating the length of
data to be cached in mod_cache.
And something really strange happen, strange for me, but maybe not for
you
what happen:
APR_BRIGADE_FOR_EACH(e,in){
look if bucket is eos, if yes, exit with all_bucket_here=1
or: look if bucket is flush, if yes, exit with unresolved_length=1
or: size += e->length;
}
on the file not cached because the MaxStreamingBuffer error, the code
above never detect a EOS bucket, so, it return a size to the following code:
if (!all_bucket_here){
if (unresolved_length || size > MaxStreamingBuffer)
exit with MaxStreamingBuffer Error.
}
Where it's really strange, is i put a debug in mod_proxy, when it
receive the data from backend server, and before passing the brigade to
the output_filter, i can detect a EOS Bucket.
So, i have a EOS Bucket found in the brigade mod_proxy will pass to
output_filter, and in the filter reading the same brigade in mod_cache
(cache_in filter), i can't find this same EOS Bucket.
if someone have an idea :)
i will continue to search on that.
Best regards,
Estrade Matthieu
