비디오 및 자막 · 다이렉트 미디어 다운로더
MIME 유형 및 콘텐츠 유형: 웹이 다운로드할 미디어 파일에 레이블을 지정하는 방법
· 배경
http 미디어 웹 기본
확장자는 파일 이름 규칙입니다. MIME 유형은 서버가 브라우저에 파일이 무엇인지 알려주는 방법입니다. 이 게시물에서는 MIME 유형이 어디서 왔는지, Content-Type이 다운로드를 구성하는 방법, 두 유형이 일치하지 않을 경우 어떤 일이 발생하는지 설명합니다.
파일 이름은 .mp4이지만 브라우저는 이를 텍스트로 처리합니다. 이는 MIME 유형이 불일치를 방지하도록 설계된 것입니다.
`.mp4`으로 끝나는 경로는 텍스트로 제공될 수 있지만 접미사가 없는 경로는 유효한 비디오를 전달할 수 있습니다. 확장자는 이름에 속합니다. HTTP Content-Type은 응답 메타데이터에 속합니다.
Direct Media Downloader는 CORS가 헤더를 노출할 때 HEAD 동안 해당 헤더를 읽고 GET에서 다시 읽습니다. 값을 표시하고 Blob 유형으로 사용하며 미디어로 보이는 값을 차단 인증서가 아닌 조언으로 처리합니다. 따라서 잘못된 헤더는 플레이어가 페이로드를 검사하기 전에 동작을 변경할 수 있으며, 특히 응답이 인라인으로 표시되는 경우에는 더욱 그렇습니다. 부정확한 레이블은 플레이어가 본문을 검사하기 전 처리에 영향을 줄 수 있으며, 특히 브라우저가 미디어를 인라인으로 렌더링하는 경우 더욱 그렇습니다.
이메일 첨부 파일에서 HTTP까지 — MIME 유형이 이메일 부분에 레이블을 지정하는 방법으로 시작되어 웹의 파일 레이블 지정 시스템이 된 방법
MIME은 메시지 부분에 레이블을 지정하는 시스템으로 시작되었으며 HTTP에서 표현을 위해 사용되는 어휘가 되었습니다. 미디어 유형에는 최상위 유형과 하위 유형이 있으며 선택적으로 매개변수가 뒤따릅니다.
레이블은 브라우저가 처리를 선택하는 데 도움이 되지만 보내는 서버가 이를 제어합니다. 메타데이터가 불량한 스토리지 버킷은 도움이 되지 않는 일반 값으로 올바른 바이트를 제공할 수 있습니다. HTTP는 파일 이름이나 문서화되지 않은 바이트 추측에서 의미를 만들어내는 모든 클라이언트보다 상호 운용 가능한 레이블이 선호되기 때문에 레지스트리를 채택했습니다. 공유 등록은 호환되지 않는 개인 명명 규칙을 메일 및 웹 클라이언트가 일관되게 해석할 수 있는 레이블로 대체했습니다.
콘텐츠 유형 헤더 읽기 — 유형, 하위 유형 및 매개변수(일반적인 경우로 video/mp4, audio/mpeg 및 application/octet-stream 포함)
`video/mp4`는 MP4 미디어 표현을 설명하고, `audio/mpeg`은 MPEG 오디오를 설명하고, `application/octet-stream`는 일반 바이너리 레이블입니다. charset 매개변수는 텍스트에 일반적이지만 미디어 코덱을 식별하지는 않습니다.
ToolAcre는 전체 헤더 문자열을 유지합니다. `looksLikeMedia` 권고는 비디오, 오디오 및 MPEGURL 레이블을 인식합니다. 옥텟 스트림은 자동 거부 없이 주의를 유발합니다. 매개변수는 미디어 유형 사양에 따라 해석되어야 합니다. 단순히 존재한다고 해서 하나의 최상위 유형이 다른 유형으로 변환되지는 않습니다. 매개변수는 해당 유형 정의에서 읽어야 합니다. 그들의 존재는 이진 응답을 다른 최상위 계열로 변경하지 않습니다.
스니핑 및 그 한계 — 브라우저가 때때로 추측하는 이유와 추측이 잘못되거나 의도적으로 비활성화될 수 있는 이유
메타데이터가 누락되거나 모호할 때 브라우저는 때때로 바이트를 검사하지만 보안과 일관성을 위해 스니핑은 제한됩니다. 서버는 일부 추측을 비활성화할 수 있으며 동작은 상황에 따라 다릅니다.
다운로더는 자체 서명 스캐너를 구현하지 않습니다. 코덱을 검사한 후 컨테이너를 열거나 선언된 MIME을 재정의하지 않으므로 호스트 메타데이터를 수정한다고 주장하지 마세요. `X-Content-Type-Options: nosniff`와 같은 보안 헤더는 추측을 의도적으로 제한하여 정확한 서버 구성에 더 큰 책임을 부여할 수 있습니다. `nosniff` 응답은 의도적으로 추측을 줄여 클라이언트 복구를 요청하는 것보다 올바른 원본 메타데이터를 더 중요하게 만들 수 있습니다.
확장자 대 MIME 유형 - 플레이어, 운영 체제 및 브라우저 도구가 실제로 신뢰하는 유형
플레이어 및 운영 체제는 확장자, MIME, 바이트 서명 및 사용 가능한 코덱을 다른 순서로 고려할 수 있습니다. 모든 소비자에게 보편적으로 승리할 수 있는 라벨은 없습니다.
ToolAcre의 대체 파일 이름은 Content-Disposition 및 최종 경로 세그먼트가 없는 경우에만 Content-Type을 사용합니다. WebM과 MP4를 인식합니다. 그렇지 않으면 일반 이름이 `.bin`로 끝납니다. 불일치는 자동으로 다른 레이블을 덮어쓰는 이유가 아니라 진단 증거이기 때문에 보관 작업 흐름에서는 두 레이블을 모두 기록해야 합니다. 불일치가 전달 구성에 대한 유용한 진단 증거이기 때문에 불일치하는 경우 두 값을 모두 보관합니다.
작업 예시: 모든 것을 옥텟 스트림으로 제공하는 스토리지 버킷 수정 — 다운로드 및 저장된 파일에 대한 변경 사항
스토리지 버킷이 모든 객체를 옥텟 스트림으로 제공하는 경우 소스에서 메타데이터를 업데이트하세요. 그러면 동일한 승인된 파일이 이후 요청에서 더 명확한 프로브 행과 올바른 유형의 Blob을 생성할 수 있습니다.
파일 이름 우선 순위가 별개이기 때문에 기존 경로 또는 콘텐츠 처리 이름은 변경되지 않고 그대로 유지될 수 있습니다. MIME 헤더 수정은 바이트를 트랜스코딩하거나 이미 다른 곳에 제공된 잘못된 확장을 수정하지 않습니다. 메타데이터 전파 후 요청을 반복하고 실제 응답을 확인합니다. 스토리지 콘솔 필드를 변경한다고 해서 모든 CDN 캐시가 현재 이를 제공한다는 것을 입증하는 것은 아니기 때문입니다. 버킷 메타데이터를 변경한 후 제어판 저장 확인을 신뢰하는 대신 캐시 전파 후 프로덕션 응답을 확인하세요.
여기서 다루지 않는 내용 — 헤더가 보장할 수 없는 파일 내부의 컨테이너 및 코덱
Content-Type은 컨테이너 유효성, 코덱, 기간, 무결성, 안전성 또는 재생 가능성을 보장할 수 없습니다. 서버는 실수로 또는 고의로 거짓말을 할 수 있으며, 전송은 약속된 기간 전에 종료될 수 있습니다.
컨테이너 및 코덱 질문에는 신뢰할 수 있는 검사 소프트웨어를 사용하십시오. 다운로더의 작업은 수신된 본문을 보존하고 관찰한 서버 레이블을 노출하는 것으로 끝납니다. 체크섬 및 특수 프로브는 정확한 바이트에 대한 신뢰도를 추가할 수 있지만 이 파일 저장 인터페이스에서는 둘 다 구현되지 않습니다. 체크섬과 컨테이너 프로브는 추가 사실을 설정할 수 있지만 두 기능 모두 이 집중 다운로더 인터페이스에 속하지 않습니다. 따라서 친숙한 라벨은 조사를 종료하지 않고 안내해야 합니다.
요약: 라벨의 중요성 — 직접 링크의 콘텐츠 유형이 Direct Media Downloader가 저장하는 내용을 결정하는 방식
모양 처리, 경고 및 대체 이름 지정에 레이블을 지정하므로 증거가 아니더라도 중요합니다. 헤더, 파일 이름, 알려진 소스, 바이트 수 및 재생을 별도의 증거로 비교합니다.
Direct Media Downloader는 부재 유형을 "서버에서 명시하지 않음"으로 보고하고 Blob 폴백 이상의 유형을 생성하는 것을 방지합니다. 이러한 제한으로 인해 호스트를 수정할 수 있는 사람이 잘못된 구성을 볼 수 있습니다. 호스트 소유자의 경우 업로드 시 메타데이터를 수정하면 각 방문자가 다운로드 후 레이블을 복구하도록 요구하는 것보다 모든 브라우저와 클라이언트에 이점이 있습니다. 이후 전달된 응답을 다시 확인하세요.