[FFmpeg-devel] [PATCH] http: make caching of redirect url optional
Eran Kornblau
eran.kornblau at kaltura.com
Thu Nov 25 08:54:39 EET 2021
> > >
> > > On Tue, 2 Nov 2021, Eran Kornblau wrote:
> > >
> > > > Hi all,
> > > >
> > > > The attached patch makes the default behavior of caching HTTP redirects optional.
> > >
> > > Is caching a redirected URL allowed per the HTTP spec? If not, then no caching should take place, or the caching should be optional, and not the default.
> > >
> > From a quick search on this, it seems that browsers by default cache 301 redirects, while 302/307 are not cached by default.
> > However, in both cases, the browser is expected to honor any Cache-Control/Expires headers.
> >
> > Changing the implementation to imitate the behavior of a browser would be more complex, since currently there is only a single "slot" in the cache.
> > For example, if we have a chain of redirects 307->301->200, and we want to cache the 301 but not the 307, we can't really do it.
> > Solving this one would require a more complex data structure, and if we add expiration/TTL to the mix, it becomes even more complex...
> >
> > Assuming we don't want to add a large chunk of code to handle this, the options I see are - 1. A simple boolean option - as proposed in this patch. We can argue about what the default should be :) but it felt safer to me to have the default behavior as it was before.
> > 2. Cache only 301's directly linked to the original URL - e.g. if we have 301->301->307->301->200, we cache only the first 2 redirects.
> > My concern here is that this would break/slow down applications that rely on the existing behavior of caching any redirect.
> >
>
> Hi,
>
> Looking for some guidance how to proceed with this...
>
> On one side, we have the minimal alternative of adding an option to the http module (as in the patch I submitted), on the other side we have the alternative of fully imitating the behavior of a browser - respect cache-control/expires, and if these headers are missing, default according to status code (301/302/307).
> We can also go with something in between - e.g., we can cache 301's that are returned directly from the original url, and avoid caching any 302/307, as well as 301's that come after a 302/307.
>
Ping...
Any objection to merge the patch that adds an option to disable the caching of redirect?
Thanks!
Eran
> Thank you
>
> Eran
>
> > Any thoughts/suggestions are welcome,
> >
> > Thank you,
> >
> > Eran
> >
> > > Thanks,
> > > Marton
> > >
> >
>
More information about the ffmpeg-devel
mailing list