TIL) HTTP 헤더 : Content-Type
HTTP 콘텐트 타입은 리소스의 미디어 타입을 나타내기 위해 존재합니다.
Media Type이란, 파일의 형식을 나타내기 위해 파일과 함께 보내지는 string입니다.
데이터를 받는 서버(request일때), 클라이언트(response일때)는 Content-Type을 보고 데이터의 형식을 파악하고, 이를 어떻게 처리할지 결정하게 됩니다.
예를 들어, 브라우저는 서버로부터의 Response를 보고, 여기의 Content-Type을 통해 컴퓨터에 보여줘야 하는 컨텐트의 타입을 알 수 있습니다.
이때 브라우저는 MIME sniffing 이라는 작업을 수행하는데요.
MIME은 "Multipurpose Internet Mail Extensions"의 약자입니다. 원래는 이메일에 있는 non-ASCII Text와 non-text binary를 정의하기 위해 고안됐다고 합니다.
현재, Mime standard에 있는 content-type들은 HTTP 프로토콜에서 request나 response의 컨텐트 타입을 파악하기 위해 쓰입니다.
브라우저는 바로 이 MIME 타입을 Content-Type을 보면서 파악합니다. (Content-Type은 MIME타입의 일부입니다)
개발자들은 Response 내용에 걸맞지 않는 Content-Type을 부여할 수 있습니다,
브라우저는 이러한 경우에도 웹사이트가 의도대로 작동할 수 있도록 Content-Type이 잘못 표시된 리소스를 분석하여 렌더링 할 수 있습니다.
여기서 MIME Sniffing 이 사용됩니다. Content_Type에 의존하기보다, response의 content에 대해 직접 분석하여서 , 브라우저는 효과적으로 mime type을 Sniffing을 통해 알 수 있습니다. MIME Sniffing의 알고리즘은 브라우저마다 상이합니다.
X-Content-Type-Options
보안 이슈를 위하여 , 브라우저가 MIME Sniffing을 하지 않도록 서버의 HTTP Response header에 X-Content-Type-Option을 줄 수 있습니다.
이 헤더의 유일한 값은 "nosniff"입니다.
문법
type/subtype
type은 카테고리이며, subtype은 개별 혹은 멀티파트 타입입니다.
application/octet-stream
Content-Type에는 수많은 종류가 있습니다. 그 중 주목할만한 application/octet-stream에 대해 얘기해보겠습니다
8 비트(1바이트) 단위의 바이너리 데이터를 의미합니다(...?) 엄밀히 따지면 모든 컴퓨터 상 파일은 binary data이긴 합니다만...
이렇게 두루뭉술하게 표현한 이유는 , 특별히 표현할만한 프로그램이 존재하지 않는 경우에 octet-steam을 사용하기 때문입니다.
보통 브라우저는 해당 타입에 대해 유저에게 실행할지 묻거나, 실행하지 않는다고 합니다.
"Content-Dispostion" 헤더를 "attachment로 줌으로써 해당 데이터를 수신 받은 브라우저가 파일을 저장, 또는 다른 이름으로 저장여부를 설정하게 할 수 있습니다.
뭐라 정의하기 애매한 경우에 해당 Content-Type을 주는 듯 합니다.
참고
https://www.coalfire.com/the-coalfire-blog/mime-sniffing-in-browsers-and-the-security
https://www.geeksforgeeks.org/http-headers-content-type/
https://pygmalion0220.tistory.com/entry/HTTP-Content-Type
http://www.webmadang.net/community/community.do?action=read&boardid=5001&page=1&seq=3
https://dololak.tistory.com/130