From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id ECB064A933 for ; Wed, 24 Apr 2024 11:06:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A807B68D2B5; Wed, 24 Apr 2024 14:06:41 +0300 (EEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C4E6468CFCE for ; Wed, 24 Apr 2024 14:06:34 +0300 (EEST) Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-516d68d7a8bso809037e87.1 for ; Wed, 24 Apr 2024 04:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martin-st.20230601.gappssmtp.com; s=20230601; t=1713956794; x=1714561594; darn=ffmpeg.org; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=XSw9V+Guue2mz3PS/o2xTSgANSW/rB7GJBUmOJhBaEM=; b=07msrTTj8m8k+PvVbXgX8JYff0AUQoGSY+7+Ogzn4IzotKf+U38nzBBFHeRBsBLstn FTczd3kCNheZMY4PU73THkUZYL8MV5dcETmNFNfnsIdqVxzZMepPj+S8JkpI0fjJQE4q fOBi95cwQXaNWWN8M/83fcl9PAnGdR1K6NFrxeUia8GOQ8DyFPZdQYaVAYriPOGgaSgm uUR3GUye/yLP4N2J98zD6SOblC3G5PsVrQA60+Jxp+tVnjghyQFR2a6a6AKZm0AGJHCt HWykCVJDAbD1J6q4X33jOnw7KTpgHS7zfl1EhHB9wHzwhGHI2qr2PKQf49XJ/6HGGLWi COIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713956794; x=1714561594; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XSw9V+Guue2mz3PS/o2xTSgANSW/rB7GJBUmOJhBaEM=; b=P8nTh9a18IDrUSDaGJtWfRbbe9NTzL8sL40gz41TuNGNhY6pPU9WOvltz3VN/1eBdB vPGGCdPWwYAEgYDCHA6MuTtTaJLFW7PMyL/DSpVn60+BFO1HeOjWVrc4YcsnD1YGZDY2 iJxPCcFgg7Kc+XqEZq1c5SxWRE3hwrpztjKGa6OPDkAUBLBLcDv8+bXFdd6IVTBOoqaC KUrrKszQJaFjErtYODDow/ue4BUlWPcI3LNHu/yXJ6rbgfgyOfU+H8lbgJJYLOP14iJx 25tInXGWGAVdpQLbAQpWJVn5zSUvuF43aAf1Zy0fraD902jPVbuwcd3qzoH3t38tZaMK JLRQ== X-Gm-Message-State: AOJu0YxFck4JzwX75srQousnoP53x1EoiV941dk0n/kPtbiVYBfZj28r v1JTWd480fse7Z5nlIChWmz/9PGmcTcQ2nbLVoOR2lmBOxNUPS0qd0ttI47RKyki+WH1KDlYYiK 08A== X-Google-Smtp-Source: AGHT+IGhaxbHp/Ala0LqEsXJZKEqw1G4Eceo8ObUACLcAoMwp++oeuktSRS6xY79uzwPveT/S3R4eA== X-Received: by 2002:a19:8c46:0:b0:518:b91e:489b with SMTP id i6-20020a198c46000000b00518b91e489bmr1609641lfj.13.1713956793835; Wed, 24 Apr 2024 04:06:33 -0700 (PDT) Received: from tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net (tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net. [2001:470:27:11::2]) by smtp.gmail.com with ESMTPSA id be41-20020a056512252900b00519780aebc9sm2266301lfb.247.2024.04.24.04.06.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 04:06:33 -0700 (PDT) Date: Wed, 24 Apr 2024 14:06:32 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20240422142547.281064-5-derek.buitenhuis@gmail.com> Message-ID: <1299142-c812-8159-42ce-f4159cb41b24@martin.st> References: <20240422142547.281064-1-derek.buitenhuis@gmail.com> <20240422142547.281064-5-derek.buitenhuis@gmail.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2 4/9] avformat/http: Add support for Retry-After header X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 22 Apr 2024, Derek Buitenhuis wrote: > 429 and 503 codes can, and often do (e.g. all Google Cloud > Storage URLs can), return a Retry-After header with the error, > indicating how long to wait, in seconds, before retrying again. > If it is not respected by, for example, using our default backoff > stratetgy instead, chances of success are very unlikely. > > This adds an AVOption to respect that header. > > Signed-off-by: Derek Buitenhuis > --- > libavformat/http.c | 12 ++++++++++++ > libavformat/version.h | 2 +- > 2 files changed, 13 insertions(+), 1 deletion(-) Is this feature standardized in a RFC, or is it some other spec somewhere? I think it would be nice with a link to a spec in the commit message here. > > diff --git a/libavformat/http.c b/libavformat/http.c > index e7603037f4..5ed481b63a 100644 > --- a/libavformat/http.c > +++ b/libavformat/http.c > @@ -138,6 +138,8 @@ typedef struct HTTPContext { > char *new_location; > AVDictionary *redirect_cache; > uint64_t filesize_from_content_range; > + int respect_retry_after; > + unsigned int retry_after; > } HTTPContext; > > #define OFFSET(x) offsetof(HTTPContext, x) > @@ -176,6 +178,7 @@ static const AVOption options[] = { > { "reconnect_on_http_error", "list of http status codes to reconnect on", OFFSET(reconnect_on_http_error), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D }, > { "reconnect_streamed", "auto reconnect streamed / non seekable streams", OFFSET(reconnect_streamed), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D }, > { "reconnect_delay_max", "max reconnect delay in seconds after which to give up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0, UINT_MAX/1000/1000, D }, > + { "respect_retry_after", "respect the Retry-After header when retrying connections", OFFSET(respect_retry_after), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, D }, > { "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, D | E }, > { "resource", "The resource requested by a client", OFFSET(resource), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E }, > { "reply_code", "The http status code to return to a client", OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E}, > @@ -386,6 +389,13 @@ redo: > reconnect_delay > s->reconnect_delay_max) > goto fail; > > + if (s->respect_retry_after && s->retry_after > 0) { > + reconnect_delay = s->retry_after; It'd be nice with a comment to clarify the units of both values here, which apparently both happen to be integer seconds? > + if (reconnect_delay > s->reconnect_delay_max) > + goto fail; > + s->retry_after = 0; > + } > + > av_log(h, AV_LOG_WARNING, "Will reconnect at %"PRIu64" in %d second(s).\n", off, reconnect_delay); > ret = ff_network_sleep_interruptible(1000U * 1000 * reconnect_delay, &h->interrupt_callback); > if (ret != AVERROR(ETIMEDOUT)) > @@ -1231,6 +1241,8 @@ static int process_line(URLContext *h, char *line, int line_count, int *parsed_h > parse_expires(s, p); > } else if (!av_strcasecmp(tag, "Cache-Control")) { > parse_cache_control(s, p); > + } else if (!av_strcasecmp(tag, "Retry-After")) { > + s->retry_after = strtoul(p, NULL, 10); Can you add a comment here, to clarify what unit the value is expressed in? // Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".