视频和字幕·直接媒体下载器
重定向、内容长度和第一个字节：直接下载的生命周期
· 工作原理
http 下载 开发人员工作流程
从下载开始到第一个字节到达，几个 HTTP 步骤在无形中发生。这篇文章解释了重定向、响应标头以及 fetch 如何报告它们，以及这对于预先命名其主机的工具意味着什么。
下载开始，五秒钟内没有任何反应 - 单击和第一个字节之间的隐形步骤
按“下载”后安静的五秒钟可以包含连接设置、重定向、服务器授权检查以及在正文块可用之前等待响应标头。进度条在字节到达之前无法前进，因此第一次更新之前的延迟不会自动冻结界面。
当主机允许跨域标头读取时，可选的 Check 链接可以通过 HEAD 公开状态、内容类型、内容长度和字节范围支持。这是一个单独的请求，而不是保证加速后续 GET 的预热，因为两个调用都使用 `cache: no-store`。具有时间细分的跟踪比按感觉等待更有用，因为它分离了浏览器公开的排队、连接、服务器等待和正文下载阶段。
请求行和标头：浏览器发送的内容 — 方法、路径、Accept 以及跨站点获取默认保留的内容
下载对经过验证的 HTTPS URL 使用 GET。获取并浏览器构造实际的请求标头；应用程序代码显式省略凭据并抑制引荐来源网址。它不会欺骗用户代理或引用者、附加登录 cookie 或添加平台令牌。
跨站点请求仍然可以包含浏览器控制的上下文，例如 Origin。确切的标头因浏览器和环境而异，因此 DevTools 是特定运行的证据。源证明了配置的方法、凭证模式、引用策略、缓存模式、重定向策略和中止信号。 HTTP 响应中标头的存在是可选的，并且 CORS 可以限制脚本可见性，因此缺少显示的总数并不表示文件为空。
重定向：当您指定的主机将您交给另一个主机时 - fetch 如何遵循 301、302 和 307 响应以及 response.url 如何显示最终地址
HEAD 和 GET 都指定 `redirect: follow`。因此，301、302、307 或其他受支持的重定向可以将请求从公布的初始 URL 移至最终资源。仅当链达到响应或根据浏览器策略失败时，Fetch 才会解析。
下载程序不会显示 `response.url`，即使 Fetch 响应公开了最终地址。要审核跃点，请保留网络日志并检查其中的重定向行。这很重要，因为联系前公告会列出所提供的主持人；它无法宣布服务器稍后选择的位置。对于 307 风格的保存，方法语义与常见的重写行为不同，这是信任浏览器跟踪而不是将每个跃点总结为相同的另一个原因。
Content-Length 和 Content-Type：响应标头承诺的内容 — 在正文完成之前如何知道大小和类型
Content-Type 标记响应并成为 Blob 类型，而正的有限 Content-Length 提供预期的总数。 GET 路径在流式传输之前拒绝超出 2 GiB 的声明总数。如果标头丢失，进度仍然不确定，实际接收到的字节会强制执行防护。
标头是来自服务器的语句，不保证正文将完成或与其标签匹配。连接可能会提前关闭，并且应用程序可能会错误配置 MIME 元数据。 ToolAcre 使用这些值进行描述、进度和命名决策，但不声称它们验证媒体内部结构。该代码还根据其最大值重新检查累积字节，确保缺失或不准确的长度不会禁用应用程序的内存边界。
工作示例：通过链接缩短器反弹的“直接”链接 - 读取网络面板中的每一跳
对于缩短的允许链接，请打开 DevTools，启用“保留日志”，然后从“检查链接”或“下载”开始。展开初始行以查看其重定向状态和暴露时的位置，然后沿着链找到其正文提供该文件的响应。将每个主机名与预期的发布者基础设施进行比较。
第一个字节时序列将等待与传输分开。一旦块到达，ToolAcre 就会报告累积的字节数；使用 Content-Length 它可以计算分数。较晚的第一个字节后跟一个快速主体表明与立即响应后跟缓慢持续传输不同的瓶颈。重试之间的比较应保持缓存设置和网络条件一致；否则，更改的时序配置文件可能会描述测试设置而不是起源。
为什么重定向对于已公布的主机很重要 - 该工具会公布您提供给它的 URL；重定向可以通向其他地方，网络面板显示位置
宣布提交的主机名很有用，但在允许重定向时不一定完整。受信任的缩短器可以合法地指向存储 CDN，而意外的链可以跨组织。该接口不会预先解析该链，因为这样做本身就需要联系。
需要白名单的审阅者应验证每个观察到的主机名或完全避免缩短链接。 ToolAcre 会阻止提交的 URL 中明显的私有目标，但它不会声称重新验证应用程序代码中的每个重定向目标；浏览器网络保护仍然是另一层。最终的 CDN 可以具有与缩短程序不同的隐私政策和管辖权，因此目的地审查应超出提交链接中可见的品牌。
这不包括范围请求、恢复或使用分块编码且无长度的流式传输的服务器
此工作流程不会发送范围请求、恢复中断的字节、强制内容长度或将分块传输帧重新解释为已知总数。 HEAD 可以报告 `Accept-Ranges: bytes`，但当前下载仍然执行一次普通 GET 并从头开始累积响应。
它也不会进行身份验证。由于省略了 cookie，重定向到登录页面可能会产生 HTML 或 HTTP 拒绝。将该页面视为可下载媒体是错误的，因此事先的 MIME 警告和最终响应标头的检查是有用的保护措施。使用分块或协议级帧的服务器可以在没有内容长度的情况下提供完整的正文，并且 UI 正确地避免了将合法的不确定性变成零。
要点：了解您的跃点 — 如何同时使用直接媒体下载器和网络面板来查看实际联系的每个主机
直接链接描述了 HTTP 旅程的开始，不一定是一台物理服务器。可观察的序列是初始 GET、任何后续的重定向、响应标头、第一个正文块、后续块、Blob 创建以及完成后的单独本地保存操作。
当目的地来源很重要时，将 Direct Media Downloader 的初始主机公告与网络面板配对。这种组合显示了联系之前的承诺以及联系之后实际发生的情况，而无需发明对可恢复传输、隐藏代理或重定向预测的支持。此时间顺序还解释了为什么仅在完成后才出现保存：该实现不会公开部分组装的 Blob，就好像它是经过验证的完整响应一样。