You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by "Mustafa Y. Acikyildiz" <ya...@webliyacelebi.com> on 2002/09/22 16:51:12 UTC

Apache Modules.

Hi.
    I'm very beginner to Apache API Programming. where to find documents?

Re: Apache Modules.

Posted by Kevin O'Donnell <ke...@kevino.net>.

> I'm very beginner to Apache API Programming. 
> Where to find documents?

I am working on a tutorial for new Apache2 module
programmers.  There are still some parts of the
documentation I need to touch up, but it's good 
enough that it may answer some of your questions.

http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html

I'm learning Apache2 + modules as I write these
tutorials, so don't think anything I do is
"the right way to do it".  ;)

Good luck,
Kevin.

-- 
Kevin O'Donnell
kevino@kevino.net
http://kevino.net

Re: Patch mod_proxy: mod_proxy + mod_cache problem

Posted by Graham Leggett <mi...@sharp.fm>.

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
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Patch mod_proxy: mod_proxy + mod_cache problem

Posted by Graham Leggett <mi...@sharp.fm>.

Ian Holsman wrote:

>> 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.

In the advanced case, yes - but in the simplest 
turn-it-on-and-it-should-just-work case the cache should be as optimised 
as possible.

> what the code should do is remember which filters where placed above the 
> cache_input filter, and restore these filters on cache_output.

This starts getting complex.

The original idea for the cache was to be transparent public proxy cache 
  layered between Apache and the browser. Because RFC2616 dictates how 
such a proxy cache should work, determining whether we have done the 
"right" thing should be relatively easy.

As we move the caching filters further towards the core of Apache, 
suddenly things start to get complicated, as there is no longer a 
guarantee that the point into which cache has been inserted is compliant 
with RFC2616 in the first place, which in turn makes things less likely 
to work predictably or correctly.

Yes, being able to put the cache wherever the admin wants is in theory a 
nice thing to have, actually practically achieving this is something 
that's going to have to be looked at pretty carefully.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Patch mod_proxy: mod_proxy + mod_cache problem

Posted by Ian Holsman <ia...@apache.org>.

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

Posted by Graham Leggett <mi...@sharp.fm>.

Matthieu Estrade wrote:

> 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

That's because there is never any such thing as the "last" brigade. 
Responses are not limited by length anywhere within the filter 
subsystem, this is the whole point behind using brigades - long 
neverending chains of data that can be of any length, even bigger than 
available RAM.

The cache filter works (should work) along the idea that each brigade is 
simply added to the one before. If this gets too big, we throw it away 
and the object is no longer cached.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."