[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Apache-based caching for https://security-tracker.debian.org/tracker/debsecan/release/1/



Hi,

This one time, at band camp, Florian Weimer said:
> * Stephen Gran:
> 
> > This one time, at band camp, Florian Weimer said:
> >> Hi,
> >> 
> >> I plan to switch the debsecan data source to URLs below:
> >> 
> >>   <https://security-tracker.debian.org/tracker/debsecan/release/1/>
> >> 
> >> I don't know how much traffic this will generate eventually.  Would it
> >> be possible to tweak the mod_proxy settings so that the local Apache
> >> server caches generated pages for a short period time (say, five
> >> minutes), but only for URLs which start with
> >> "https://security-tracker.debian.org/tracker/debsecan/release/1/";, e.g.
> >> <https://security-tracker.debian.org/tracker/debsecan/release/1/sid>?
> >
> > mod_cache is a mildly complicated (and potentially dangerous) beast.
> > Please have a look over
> > http://httpd.apache.org/docs/2.2/mod/mod_cache.html and linked pages
> > (especially the caching guide).
> 
> Sure, those are the perils of caching.
> 
> > Let us know what content (if any, including headers) should be excluded
> > from caches.  Assume that we know nothing about your application,
> > and ask advice if you're unsure if something should be cached or not.
> > As I said, caching can be dangerous if misused - you can present one
> > user's content to another user very easily.  I don't think debsecan has
> > that sort of problem, but you should consider if headers change the way
> > your application responds and work with that idea in mind.
> 
> Everything below
> 
>   https://security-tracker.debian.org/tracker/debsecan/release/
> 
> is public and not client-dependent at all, so caching that will not
> cause any trouble.

Great, that makes it easy.

> > We can tune it to only cache things at the mentioned path.  Is
> > there any reason we should be hard coding the expiry time of cache
> > objects?  Can you not set cache headers in the application?
> 
> debsecan doesn't set any caching headers, and the server side is not
> very cache-friendly, either, because it does not supply Last-Modified
> headers etc.  We should change that eventually, but it's not a
> priority right now.

If we're going the route of blanket default cache times for the whole
site, I'd frankly be happier if you were the one controlling the timeouts.
It would save you having to round trip through us as you get things going,
and it will significantly reduce our overhead.  Most frameworks make it
easy to set additional headers on pages by default.

> I've uploaded a new version of debsecan with the
> security-tracker.debian.org URL to unstable.  Let's see how it goes
> and apply the caching if needed.

OK.  That works too.

Cheers,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature


Reply to: