mlibbey commented on PR #13238: URL: https://github.com/apache/trafficserver/pull/13238#issuecomment-4634656491
> As commented, this actually fixes an interesting issue (accidentally "prefetching" of likely uncacheable objects). As such, I asked Claude to document this, so here's the suggestion: > > ``` > --- a/doc/admin-guide/plugins/prefetch.en.rst > +++ b/doc/admin-guide/plugins/prefetch.en.rst > @@ -33,6 +33,15 @@ Description > On every **incoming** URL request, the plugin can decide to pre-fetch the > **next object** or more objects based on the common URL path pattern and a > pre-defined pre-fetch policy. > > +.. note:: > + > + The plugin keys its fetch policy off the request's **cache key**, which is > + only available once ATS has resolved the cache lookup URL. It therefore acts > + at the ``CACHE_LOOKUP_COMPLETE`` hook. On transactions where ATS skips the > + cache lookup entirely -- non-cacheable methods, some internal-redirect legs, > + or caching disabled (``proxy.config.http.cache.http: 0`` or per remap) -- > + the plugin never triggers a prefetch. Prefetching into a cache that will not > + be consulted is a no-op, so this is expected. > + > Currently, most HLS video urls follow a predictable pattern, with most URLs > containing a segment number. Since the segments are ~10s of content, the normal > usage pattern is to fetch the incremental segment every few seconds. The CDN > ``` Thanks! Added a similar section in now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
