HEAD 메서드를 우리의 서비스 중 하나에 빌드하여 클라이언트가 다운로드할지 여부를 결정하기 전에 콘텐츠 형식 및 크기를 들여다 볼 수 있도록하려고합니다.HTTP HEAD 응답 - Content-Length 설정
어떻게 응답 헤더의 Content Length를 설정할 수 있습니까? HttpContext를 사용하면 ContentType, Encoding 등이 노출되지만 일부 내용이 응답에 추가 될 때이 값이 일반적으로 프레임 워크에 의해 추가되는 것으로 가정하므로 길이를 지정할 수 없습니다.
이 작업을 수행하는 또 다른 방법이 있습니까, 아니면 HEAD 요청의 길이를 잘못 설정 했습니까? 실제로 리소스의 크기를 반환하는 사용자 지정 헤더를 추가해야합니까?
나는 Content-Length이 리소스의 크기가 아닌 응답 본문의 크기를 지정한다고 생각합니다. 따라서 응답이 HEAD 인 경우에는 의미가 없습니다.
편집 : 사양은 말한다 :
헤드 방법은 서버가 응답 메시지에 Message-Body를 반드시 리턴해야한다는 것 이외에는 GET과 동일하다. HEAD 요청에 대한 응답으로 HTTP 헤더에 포함 된 메타 정보는 GET 요청에 대한 응답으로 전송 된 정보와 동일해야합니다 (SHOULD). 이 방법은 엔티티 본문 자체를 전송하지 않고 요청에 의해 암시 된 엔티티에 대한 메타 정보를 얻는 데 사용할 수 있습니다. 이 메소드는 유효성, 액세스 가능성 및 최근 수정에 대한 하이퍼 텍스트 링크를 테스트하는 데 자주 사용됩니다.
HEAD 요청에 대한 응답은 응답에 포함 된 정보가 이전에 캐시 된 엔티티를 해당 자원에서 업데이트하는 데 사용될 수 있다는 점에서 캐시 가능할 수 있습니다 (MAY). Content-Length, Content-MD5, ETag 또는 Last-Modified의 변경으로 표시되는 것처럼 캐시 된 엔터티가 현재 엔터티와 다르다는 것을 새로운 필드 값이 나타내면 캐시는 캐시 항목을 부실로 취급해야합니다 (MUST).
은 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
이 내 위의 진술이 잘못 제안합니다. 특히 후자는 HEAD가 Content-Length 헤더를 가질 수 있음을 강력히 제안합니다.
고마워요 - 그것의 읽기는 머리가 동일하므로 길이가 GET에 반환되는 크기로 설정 될 것이라고 기대했다. 대부분의 경우 헤더가 있는지 확인하여 리소스가 변경되었는지 확인합니다. 우리의 경우에는 크기에 따라 다운로드할지 여부를 사람들에게 알리고 싶습니다. –
그리고 그것이 맞는 해석이라고 생각합니다. 그렇다고해서 모든 배우가 실제로이 방법을 구현한다는 보장은 아닙니다. – troelskn