Hi,
I'm just going through my todo's and have one on whether I should be
performing blocking reads for buckets in my input filter. I've read the
guide to writing output filters which describes using non blocking and
sending flush buckets but couldn't find anything on input filters. Is
On 2 September 2010 13:29, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 9/1/2010 10:17 PM, dave b wrote:
Why not just fix it now and not worry? ...
It will help if you can provide a specific use case for graceful failure.
A segfault/dereference of NULL pointer provides a very specific
On 2010-07-11 at 01:40, n...@apache.org wrote:
Author: niq
Date: Sun Jul 11 05:40:27 2010
New Revision: 962985
* mod_disk_cache: Decline the opportunity to cache if the response is
a 206 Partial Content. This stops a reverse proxied partial response
@@ -214,6 +225,9 @@ PATCHES
On 09/02/2010 04:09 PM, Dan Poirier wrote:
On 2010-07-11 at 01:40, n...@apache.org wrote:
Author: niq
Date: Sun Jul 11 05:40:27 2010
New Revision: 962985
* mod_disk_cache: Decline the opportunity to cache if the response is
a 206 Partial Content. This stops a reverse proxied
On 2010-09-02 at 12:37, Ruediger Pluem rpl...@apache.org wrote:
On 09/02/2010 04:09 PM, Dan Poirier wrote:
On 2010-07-11 at 01:40, n...@apache.org wrote:
Author: niq
Date: Sun Jul 11 05:40:27 2010
New Revision: 962985
* mod_disk_cache: Decline the opportunity to cache if the
On Thu, 02 Sep 2010 10:09:00 -0400
Dan Poirier poir...@pobox.com wrote:
I think right now mod_cache doesn't let any 206 responses get to the
cache backends, but if that change is made to let them by, then backends
that don't correctly implement caching of 206 responses will need to
decline
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade *b);
Right now, mod_cache expects a cache
On 02 Sep 2010, at 7:01 PM, Nick Kew wrote:
Indeed. I guess my comment in STATUS was down to reviewing that
backport proposal (and checking the RFC) before I saw the other one.
I guess the real question is: why enable it in the abstract, in the
absence of a backend implementation? Surely
On 09/02/2010 07:16 PM, Graham Leggett wrote:
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade
On 9/1/2010 10:29 PM, William A. Rowe Jr. wrote:
On 9/1/2010 10:17 PM, dave b wrote:
Why not just fix it now and not worry? ...
But if you can illustrate a few, the community is happy to evaluate your
examples, which is what Jeff has politely suggested to you.
And if you can't illustrate a
On 2 Sep 2010, at 18:20, Graham Leggett wrote:
On 02 Sep 2010, at 7:01 PM, Nick Kew wrote:
Indeed. I guess my comment in STATUS was down to reviewing that
backport proposal (and checking the RFC) before I saw the other one.
I guess the real question is: why enable it in the abstract, in
Hi all,
A second issue I would like to attack this weekend is the issue of
atomic cache updates in mod_cache.
Right now today, two functions are provided to add and/or update a
cache entry:
apr_status_t (*store_headers)(cache_handle_t *h, request_rec *r,
cache_info *i);
On 03 Sep 2010, at 12:53 AM, Nick Kew wrote:
I disagree about 'broken': a cache isn't *required* to cache ranges.
I definitely agree that a cache isn't required to cache ranges, but
right now mod_cache actively forbids the caching of ranges by an
implementation, and that's the behaviour
And if you can't illustrate a few explicit cases, further abstract arguments
are likely to be politely, but firmly, ignored. There are good C language
forums for folks to carry on such religious arguments.
Or to put it another way, the dev@ group here is most certainly not worried
about the
14 matches
Mail list logo
