[FFmpeg-devel] [PATCH] http: make caching of redirect url optional

[Eran Kornblau]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Ronald S. Bultje
> Sent: Sunday, 26 December 2021 16:07
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] http: make caching of redirect url optional
> 
> Hi,
> 
> (I was asked to respond since I'm listed as HTTP maintainer, not sure I should be since I'm mostly working on video codecs nowadays.)
> 
> On Tue, Nov 2, 2021 at 9:00 AM Eran Kornblau <eran.kornblau at kaltura.com>
> wrote:
> 
> > The motivation for this feature is S3 signatures – currently we have a 
> > problem where S3 signatures cannot be created with an expiration of 
> > more than 12H. In some cases, a transcoding task may execute for more 
> > than that.
> > If we use a pre-signed S3 URL, and ffmpeg disconnects/seeks after the 
> > expiration of the URL, it will fail.
> >
> > The solution we are planning is to have some local server on the 
> > machine running ffmpeg that will generate an S3-signature, and 
> > redirect to the full pre-signed URL. For this to work, I need to 
> > disable the caching of redirects, and have ffmpeg always start from 
> > the initial URL.
> > The nice thing about this solution is that the video data is pulled 
> > directly from S3 – in other words, the local server doesn’t hold any 
> > real load, it just builds the signature and returns a redirect.
> >
> 
> Uhm... This is a really weird solution, but it does look right.
> 
> Generally speaking, we're typically concerned about the default being the right behaviour. I would say that (maybe after some time, at the next ABI break or so), 0 should be the default, not 1. This is the same as what Marton/Hendrik said also, I think, so consider this consensus. I would just do that with the appropriate ABI macros so the default behaviour changes at the next bump.
> 
Thank you, Ronald!

I attached a new patch with the change you requested, I hope I understood your intention correctly...

Also -
1. Rebased it against latest master - there were some changes in http since I submitted...
2. Fixed a leak that I created in the original patch - I tried to match the 'location' field when adding 'uri', but missed the fact that 'location' is freed automatically, being an option.

> Patch itself is fine, it has some whitespace change at line 430 and 621 that is not really necessary, but otherwise no objections from me.
> 
These 2 whitespaces were added intentionally - to have one block that handles 'location', and another block that handles the new 'uri' field.

> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7C%7C310f5d2e188648e50d0308d9c8790674%7C0c503748de3f4e2597e26819d53a42b6%7C1%7C1%7C637761244390439784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5YhHSjTVN5v7BQdMgkZ2tXUA5tZGbv8Yb1MN8x%2Ffsd4%3D&reserved=0
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>

Thanks,

Eran

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-http-make-caching-of-redirect-url-optional.patch
Type: application/octet-stream
Size: 4176 bytes
Desc: 0001-http-make-caching-of-redirect-url-optional.patch
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20211227/e578e66e/attachment.obj>