On Wed, Aug 7, 2013 at 4:15 PM, Roderich Schupp <roderich.sch...@gmail.com> wrote: > Actually I think that your worst case scenario should be illegal > and that Apache should close a connection when the user changes > between requests.
I disagree that this sort of scenario should be disallowed. It's a fundamental feature of HTTP that each request is independent. I realize it's horribly inconvenient for us that HTTP is stateless, but it's the reality. On Thu, Aug 8, 2013 at 5:41 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > I don't see problem here: in worst scenario cache size would same as > authorization file. So even for large authorization files memory usage > will be limited. Yes I realize it's not entirely unbounded. It's my opinion that caches should always have bounds outside of just the source data. It is much better to limit the cache and then run slower in these rare circumstances than it is to simply fail entirely due to out of memory conditions. > Other approaches are: > 1. use svn_cache__t object to store cached values I think this is the route you have to go if you want to set limits. I'm not sure how reasonable it is to keep only doing per-connection caches with this though. Caching beyond the connection means you have to start dealing with cache invalidation from changes to the conf file. > 2. Factor out configuration file parser and store authorization > settings in our own hash table with interesting cached values. I tend to think there's a lot bigger savings from this because the config parser is certainly not storing things in a way that is optimal for an authz system.
