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 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 tha
> -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 Leg
On Thu, 21 Sep 2006, Graham Leggett wrote:
Hmmm - this affects the case where another process/thread is delivering
from a still-being-cached entity.
If the lead thread decides to stop, and other threads are following, the
other following threads will deliver CacheMaxFileSize data, and cut the
r
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 fi
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, we
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
>"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
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
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 actuall
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
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
>>>orig
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
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
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 entiti
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, 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.
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 out-of
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 muc
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, if
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,
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
/cach
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 do
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 the
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
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 methods are only called when an
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
> /cache/x/y/
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 performance.
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
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 a
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.
* N
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.
Thi
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.
It'
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 the
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
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
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?
http://verdesmares.com/Apache/patch
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
htt
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 t
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 it
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 fo
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 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, 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 t
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 th
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_cach
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 heade
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...
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 l
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 ca
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 pound
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 con
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
53 matches
Mail list logo