Issac Goldstand wrote:
In any case, if we're proxying for an HTTP/1.0 client using HTTP/1.1
(too tired to check if mod_proxy preserves HTTP version - but will try
to check tomorrow if no one beats me to it), or even serving cached
content to a 1.0 client originally received by a 1.1 request,
On Wed, September 20, 2006 9:50 pm, Ruediger Pluem wrote:
You can set a max cache file size (CacheMaxFileSize) which prevents
caching files that are larger then
a specfic size. This is checked after each bucket is written to the disk.
If the
stream is larger then the max file size the file
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Donnerstag, 21. September 2006 11:38
An: dev@httpd.apache.org
Betreff: Re: mod_cache responsibilities vs mod_xxx_cache
provider responsibilities
On Thu, 21 Sep 2006, Graham Leggett wrote:
This means the backend
On Thu, September 21, 2006 11:05 am, Issac Goldstand wrote:
Based on that, it seems to me that the sensible thing to do would be to
update the header file to include trailers after the response is
complete (and send them as-is as trailers to the initial client). If
we're already doing that,
tor 2006-09-21 klockan 12:18 +0200 skrev Plüm, Rüdiger, VF EITO:
IMHO this waits for a DoS to happen if the requestor can trick the backend
to get stuck with the request. So one request of this type would be sufficient
to DoS the whole server if the timeout is not very short.
How would this
On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets cached
log (sql, db, whatever) that /blah/foo/bar.html is cached as
On Mon, 18 Sep 2006, Brian Akins wrote:
Graham Leggett wrote:
I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.
Everyone should be mounting cache directories noatime,
Niklas Edmundsson wrote:
On Mon, 18 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
* Only one session caches the same file.
Easy to do if we use deterministic tmp files and not the way we
currently do it. Then all you have to do is when creating temp files
use O_EXCL.
Or,
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a
performance killer oddly enough... Our frontends had no problems
surviving 1k requests/s during the latest mozilla-update-barrage.
1k requests/second is not really that
Graham Leggett wrote:
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files
On Wed, 20 Sep 2006, Brian Akins wrote:
Niklas Edmundsson wrote:
don't care about performance...
Actually, cache on xfs mounted with atime doesn't seem to be a performance
killer oddly enough... Our frontends had no problems surviving 1k
requests/s during the latest mozilla-update-barrage.
Issac Goldstand wrote:
I don't understand why bother getting so complex. Touch/truncate the
body file when storing the header, and then a missing body means things
have gone amok - retry the request. Conversely, a zero-length, or C-L
body length means another thread is working on the body.
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code does to handle chunked entities
Brian Akins wrote:
Issac Goldstand wrote:
I don't understand why bother getting so complex. Touch/truncate the
body file when storing the header, and then a missing body means things
have gone amok - retry the request. Conversely, a zero-length, or C-L
body length means another thread is
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
I am not sure what the current cache code
On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from an
origin doing chunks?
Ruediger Pluem wrote:
On 09/20/2006 08:27 PM, Issac Goldstand wrote:
Graham Leggett wrote:
On Wed, September 20, 2006 5:27 pm, Brian Akins wrote:
unless 0 is a valid content-length, which it can be. Also, what about
when we are reading something in without a know C-L, for example from
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first before actually
Ruediger Pluem wrote:
On 09/20/2006 09:59 PM, Issac Goldstand wrote:
Ruediger Pluem wrote:
First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
Yes, there is a reason why we cannot do this: This would create a possible
DoS, because we have to
suck in the whole response first
This differs from a content coding in that the transfer-coding is a
property of the message, not of the original entity.
Based on that, it seems to be ok. However, we'd have to remove strong
ETags as a side-effect if it was done (since strong ETags change when
entity headers
tor 2006-09-21 klockan 00:19 +0300 skrev Issac Goldstand:
The only really relevant line I saw (in a quick 15 minute review) is RFC
2616-3.6 (regarding transfer-encodings):
Transfer-coding values are used to indicate an encoding
transformation that has been, can be, or may need to be
On Sun, 17 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple files
and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
*
On Mon, September 18, 2006 9:35 am, Niklas Edmundsson wrote:
The easiest way to deal with this might be to have a timeout, if the
body hasn't shown up in $timeout time then something went bad,
DECLINE, meaning that the cache layer thinks it should cache the file
and acts accordingly. You
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets
cached log (sql, db, whatever) that /blah/foo/bar.html is cached as
/cache/x/y/something.meta. Then it's very easy
Graham Leggett wrote:
I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.
Everyone should be mounting cache directories noatime, unless they don't
care about
Brian Akins wrote:
Niklas Edmundsson wrote:
Extra tracking sounds unnecessary if you can do it in a way that
doesn't need it.
It's not extra it just adding some tracking. When an objects gets
cached log (sql, db, whatever) that /blah/foo/bar.html is cached as
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
Also, those statistics could be updated asynchronously by using a queue
so that statistics doesn't slow down a busy web server.
--
Brian
Brian Akins wrote:
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
albeit expensive to keep track of, but I don't understand this specific
example.
It's not expensive, as these
Brian Akins wrote:
Issac Goldstand wrote:
I can see how other tracking information (like how often the
cached entity is accessed, last access time, etc) would be useful,
Also, those statistics could be updated asynchronously by using a queue
so that statistics doesn't slow down a busy
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files out-of-sync issues. Ever.
Niklas Edmundsson wrote:
However, I don't see how you can do a lockless design with multiple
files and an index that can do:
* Clients read from the cache as files are being cached.
* Only one session caches the same file.
* Header/Body updates.
* No index/files out-of-sync issues. Ever.
On Fri, 15 Sep 2006, Brian Akins wrote:
The separate header and body files work wonderfully for performance (filling
multiple gig interfaces and/or 30k requests/sec. or rather modest hardware).
If you have them all in one, it can make the sendfile for the body
cumbersome.
If you write to
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
The thing is that I've been pounding seriously at mod_disk_cache to
make it able to sustain rather heavy load on not-so-heavy equipment,
and part of that
Niklas Edmundsson wrote:
If I remember correctly the code in 2.2.3 only does whole-file
revalidation,
No, it can have a stale handle that it makes fresh if it gets a 304.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
The thing is that I've been
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that
it be possible to modify the headers on a cached entry independently of
the
Niklas Edmundsson wrote:
The stuff is used in production and seems stable, however I haven't had
any response to the first (trivial) patch sent so I don't know if
there's any interest in this.
Can you post the patch again? Also, if you attach it to a bugzilla
entry, it's less likely to get
This looks familiar. I seem to remembering seeing patches for this a
few months back. Were they not committed to trunk? If not, is there
any reason why not? I'd hate to spend serious time making modifications
only to have to redo the work when this (pretty major) patchset gets
committed...
On Thu, 14 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file for
body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that it be
possible to modify the
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one
file for body in mod_disk_cache
On 14/09/2006, at 04:39, Graham Leggett wrote:
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one
file for body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires
that it be possible to modify the
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory for the cache. If it doesn't work now, it
needs to
On 14/09/2006, at 05:08, Issac Goldstand wrote:
This looks familiar. I seem to remembering seeing patches for this a
few months back. Were they not committed to trunk? If not, is there
any reason why not? I'd hate to spend serious time making
modifications
only to have to redo the work
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers
On 14/09/2006, at 08:48, Graham Leggett wrote:
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will
On Thu, September 14, 2006 2:07 pm, Davi Arnaut wrote:
The cache is required to send to the client the most up-to-date
response, it doesn't mean it must cache it.
As I recall once cached, if an entry is stale and is revalidated, the
headers coming back with the 304 Not Modified must replace
On 14/09/2006, at 09:21, Davi Arnaut wrote:
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
On Thu, 14 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
Hi all,
I've been hacking at mod_cache a bit, and was surprised to find that
part of the decision to serve previously cached content or not was being
made by the backend provider and not mod_cache; specifically, the
expiration date of the content seems to be checked by mod_disk_cache (as
part of
On 13/09/2006, at 16:29, Issac Goldstand wrote:
Hi all,
I've been hacking at mod_cache a bit, and was surprised to find that
part of the decision to serve previously cached content or not was
being
made by the backend provider and not mod_cache; specifically, the
expiration date of the
51 matches
Mail list logo
