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 B6AC045A5B for ; Sat, 13 May 2023 17:06:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5210768BF06; Sat, 13 May 2023 20:06:35 +0300 (EEST) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1821668ABBC for ; Sat, 13 May 2023 20:06:28 +0300 (EEST) Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-ba7831cc80bso59952276.0 for ; Sat, 13 May 2023 10:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683997587; x=1686589587; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=jAM/KEZWCEMP+RYu3yX30pSQ3UfHvrJWc+UmeNoLyTU=; b=DLL5NRTohuPtSKXI3EQ/fLlGEMWgT4kPeLc9NAEa1CuENLQvPibYMBIka8f5QYeUva bfNepypDjDeuM0nfiwCvMWhxxzVtaQ1A4RLevRfMOyVfsxBLOt3fOrfNaKSq6gmC0qfA gcPlsLNcdFJBgNdJNQeWNKl2IgoAYrVIDbIo/MZOCS30pqNtpfkh7IqDyuDDsnfgbxUy l2uN2IhzXBKRjGzf/IUKclODadyKUuw154Q9d0RzEvxkBH8OnAAxzp13xVfFbZz4hukq ahFxygUTHBZQkzWcS/q54MZNQk91fpOo4rHmnLD6gRduMjMWUdO9T0MZPV23v13MT8Nc 6sVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683997587; x=1686589587; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jAM/KEZWCEMP+RYu3yX30pSQ3UfHvrJWc+UmeNoLyTU=; b=gqqxwDTqPw7Xp4nfd1aWKHP0BO0SsXL2yINoRPKyk4NUCtYJrR+qQiUedQ5kEjsZot tPoCHgFGanrbxY3js2Mj6JH24TsEGuR2T7/2xFvmmrQLQww9U5pIp7CQMDzEBFvlkjj4 ZGCR2WxNFk7mJHNefjiakdfedu9Agx++C/bEvAryDvs7rUfwxy45KJDZYcwchMPyi5gy 0V/j3eqXdrHZLn+3Kk0BnOXPaW2I9bHgXf9HdgSsEXaiM1is+iDOGp2/QqsI+yCEzJqL 4ICWCFBgmBnPbBJxq1iNnmT33NxtnWPLPz2+5eSNoIvZlGNug91sSjcPt1zzbw1kF1fh lvoA== X-Gm-Message-State: AC+VfDzwhnexO7f1kBy/0W8DP/goMO1NZ5Rd7wUMK/Rwbu6SGu3oenSE 3pSGksjgZbOSRmDZ34yAMuOpabkmSO0= X-Google-Smtp-Source: ACHHUZ66/kdsU1C03nH0rpAJyntEaBiQjd6Oeq4/+F+b3btVIGxP7Qo/8GtHBa1Awpo5I0jZry7HEA== X-Received: by 2002:a81:570d:0:b0:55a:4dd1:f550 with SMTP id l13-20020a81570d000000b0055a4dd1f550mr24385797ywb.3.1683997587071; Sat, 13 May 2023 10:06:27 -0700 (PDT) Received: from [192.168.1.35] (c-98-224-219-15.hsd1.mi.comcast.net. [98.224.219.15]) by smtp.gmail.com with ESMTPSA id u204-20020a8184d5000000b00559d3586ab9sm6536238ywf.10.2023.05.13.10.06.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 10:06:26 -0700 (PDT) Message-ID: Date: Sat, 13 May 2023 13:06:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: ffmpeg-devel@ffmpeg.org References: <20230512202622.29531-1-leo.izen@gmail.com> <20230513145422.GG1391451@pb2> Content-Language: en-US-large From: Leo Izen In-Reply-To: <20230513145422.GG1391451@pb2> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: look for trailing GET headers with m3u8 extension check 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 5/13/23 10:54, Michael Niedermayer wrote: > On Fri, May 12, 2023 at 04:26:22PM -0400, Leo Izen wrote: >> After commit 6b1f68ccb04d791f0250e05687c346a99ff47ea1 we refuse to use >> URLs of the form https://foo.bar/baz.m3u8?foo=bar because it fails the >> file extension check. This commit strips the ?foo=bar at the end before >> checking the file extension. >> >> Signed-off-by: Leo Izen >> --- >> libavformat/hls.c | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/libavformat/hls.c b/libavformat/hls.c >> index 11e345b280..6a97cced17 100644 >> --- a/libavformat/hls.c >> +++ b/libavformat/hls.c >> @@ -2534,7 +2534,16 @@ static int hls_probe(const AVProbeData *p) >> strstr(p->buf, "#EXT-X-TARGETDURATION:") || >> strstr(p->buf, "#EXT-X-MEDIA-SEQUENCE:")) { >> >> - if (!av_match_ext(p->filename, "m3u8,hls,m3u")) { >> + char *request_qmark = strchr(p->filename, '?'); >> + int match_ext; >> + >> + if (request_qmark) >> + *request_qmark = '\0'; >> + match_ext = av_match_ext(p->filename, "m3u8,hls,m3u"); >> + if (request_qmark) >> + *request_qmark = '?'; >> + >> + if (!match_ext) { >> av_log(NULL, AV_LOG_ERROR, "Not detecting m3u8/hls with non standard extension\n"); >> return 0; >> } > > the av_match_ext here matches the probe code > all should be fixed. Also differences between local files and urls should > be considered in extension extraction If you're requiring that we check that a file is local before stripping tailing request headers, how would you check if a file is local? having a scheme:// is not sufficient to make that check, as file:// is a valid scheme. You could check for https?:// I suppose, but the spec doesn't actually require that HTTP be used (section 2): Data SHOULD be carried over HTTP [RFC7230], but, in general, a URI can specify any protocol that can reliably transfer the specified resource on demand. Do note that your original patch is not spec-compliant. RFC 8216 section 4 says the following: Each Playlist file MUST be identifiable either by the path component of its URI or by HTTP Content-Type. In the first case, the path MUST end with either .m3u8 or .m3u. In the second, the HTTP Content-Type MUST be "application/vnd.apple.mpegurl" or "audio/mpegurl". Clients SHOULD refuse to parse Playlists that are not so identified. This implies that (1) .hls is not a valid extension if that is being used, and (2) a valid HLS mimetype in a content-type header is sufficient to mark a file as HLS regardless of the extension used. So the extension check should only be done for local files or files that don't serve an appropriate content-type header, should you wish to do the extension check. However, HTTP streams are always safe (mpv marks them as such, for example) so the original patch is still a bit silly. - Leo Izen (Traneptora / thebombzen) _______________________________________________ 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".