0
Range 헤더는 Content Negotiation과 어떻게 작동합니까? 설명 하겠지만 먼저 다음 사항에 동의하겠습니다. HTTP는 상태 비 저장 프로토콜입니다.HTTP 콘텐츠 협상 및 범위 헤더
HTTP 서버가 단일 자원의 다중 표현을 보낼 수있는 경우 컨텐츠 협상을 사용하여 보낼 표현을 나타냅니다. 클라이언트는 선호도 (예 : 영어 및 GIF)를 표시 한 다음 서버가 준수하거나 - - 서버가 어떤 경험적 평가를 통해 클라이언트를 보낼 표현을 선택할 수없는 시나리오에서.
지금까지 그렇게 좋았지 만 ... Range을 믹스에 넣으면 어떻게 될까요?
는 다음과 같은 시나리오를 상상해 :
존 파리 공항에 그의 브라우저가 HTTP 요청을 보냅니다. 웬일인지, 그의 브라우저는 언어 또는 압축 형식의 컨텐트 유형을 나타내지 않습니다. 그것으로 갈 거의 가지고 있기 때문에
GET /uri HTTP/1.1 Host: example.com, 서버는, 몇 가지 추론을 통해합니다 (IP는 프랑스의 것으로 인식.)
URI에의 프랑스어 표현을 보낼 을 결정200 Okay Accept-Ranges: bytes Content: text/html Content-Language: fr ....data...Mid-transfer, John은 다운로드를 중지하여 항공편을 잡습니다. John은 뉴욕에 도착하면 다운로드를 다시 시작합니다.
GET /uri HTTP/1.1 Host: example.com Range: 2000-3000다시, 고객의 취향에 약간의 정보와 함께 서버 이번에함으로써 URI의 영어 표현합니다 (IP는 뉴욕의 것으로 인식.)
을 보내 을 결정 이 시점에서 파일의 일부는 프랑스어로되어 있고 다른 부분은 영어로되어 있기 때문에 파일이 손상되었습니다.
추측 :
- 그것은 가능 클라이언트 (
Accept: text/html Accept-Language: fr아래) 두 번째 요청에 대한 서버에서 다시 정보를 전송 하기 위해 첫 번째 응답에서 콘텐츠 형식과 언어를 기억합니다. 그러나 nether RFC2616도 RFC7233이 (심지어 권장 사항)에 관해서는 아무 것도 아니기 때문에 나는 HTTP 클라이언트 이 드물다는 것을 믿지만 ... 아직 테스트를 거쳤습니다.
주 : 위의 시나리오에서
- , 우리는 쉽게 클라이언트 환경 설정을 보내고 다른 추론에 다시 떨어지는 여전히 준수 할 수없는 서버를 가지고 ... 그리고있을 수 있습니다. 문제가 지속됩니다.다른 예로서
- 이 문제는이 다른 SO 질문에 존재할 것이다 : Sample http range request session
TL; DR에게
GET /uri HTTP/1.1
Host: example.com
Accept: text/html; q=1.0, text/plain; q=0.8, */*; q=0.1
Accept-Language: en; q=1.0, */*; q=0.1
Range: 100-200
을 상기에서, 상기 범위의 어느 표현에 적용 요청한 자원?