투명 프록시 용 HTTP 구문 분석기를 작성하고 있습니다. 나를 괴롭히는 것은 Transfer-Encoding: chunked의 사양에 언급 된 Trailer:입니다. 그것은 어떻게 생겼습니까?HTTP 청크 인코딩. SPEC에 언급 된 '예고편'의 예가 필요합니다.
일반적으로 HTTP 청크는 다음과 같이 끝납니다. 나는 뒤에 헤더의 어떤 종류가있는 경우 청크의 끝을 감지하는 방법을 약 혼란 스러워요 무엇
0\r\n
\r\n
...
업데이트 : 그 간단한 \r\n\r\n 즉 비어를 믿고 라인은 후행 헤더의 끝을 감지하기에 충분합니다 ... 맞습니까?
0 \ R \ 없음
SomeAfterHeader : TheData \ R \ n
\ R \ n 말하면
, \r\n\r\n 찾게 충분 , 평신도의 조건으로 : 공백 라인. 청크 분할 전송의 끝을 감지합니다. 그러나 이렇게하기 전에 각 청크를 읽는 것이 매우 중요합니다. 청크 된 데이터 자체에는 빈 줄이 포함될 수 있으므로 스트림의 끝으로 잘못 감지됩니다. 트레일러에 관한
"... \ 빈 \ n \ r \ n, 평신도의 용어로 보면 충분합니다. * 빈 줄 *. 청크 분할 전송의 끝을 감지합니다. " 이것은 나에게 잘못된 것처럼 보인다. [The ABNF] (http://tools.ietf.org/html/rfc7230#section-4.1)는 매우 명확합니다. 청크 크기에 따라 청크 데이터를 읽어야합니다. 청크 크기가 0 인 것을 발견하면 마지막 청크를 찾았습니다. 나머지는 훌륭하지만, 그 문장을 고쳐야한다고 생각합니다. –
@ unixman83 : 답변이 정확하지 않은 경우 (Hawkeye Parker가 지적한대로)이를 수정하거나 승인 된 답변으로 표시를 취소해야합니다. SO 사용자를 오도하지 마십시오. 저를 비롯한 많은 사람들이 종종 신뢰할 수 있기 때문에 모든 의견을 읽지 않고 SO 응답을 당연하게 생각합니다. 이것은 방문자가 "캐치해야"하는 "예외"인 것 같습니다! –
:
당신이 참고로 뒤에 헤더의 목록은, 트레일러 헤더에 지정해야합니다.
Trailer = "Trailer" ":" 1#field-name
Gourley와 Totty이 예제를 제공합니다 : Section 14.40 of RFC 2616에서
BNF이있다 콘텐츠 길이가 명시 적으로 금지되어 있기 때문에
Trailer: Content-Length
(그들이이 예제를주는 것은 이상 14.40의 후미 헤더)
Shiflett는 다음 예를 제공합니다.
0Section 3.6.1 of RFC 2616의 BNF는 당신이 찾고있는 무엇 : 후행 헤더와 메시지의 끝 부분에 대해서는 1,238,
.
Chunked-Body = *chunk
last-chunk
trailer
CRLF
last-chunk = 1*("0") [ chunk-extension ] CRLF
trailer = *(entity-header CRLF)
그래서 마지막 덩어리 2 후행 헤더는 다음과 같습니다 :
다음0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>
사람들은 왜 단순한 경우에만 설명하는 예제를 제공합니까? 예고편에 여러 헤더가있는 경우 어떻게합니까? 쉼표로 구분 된 목록을 사용하고 있습니까? – developerbmw
왜 사람들이 스스로 사양을 읽지 않아도됩니까? 귀하의 질문에 대한 답변은 이미 내 대답입니다. 단서를 원해? 1 # 필드입니다. 다른 사람? 여기로 이동하십시오 : http://tools.ietf.org/html/rfc2616#section-2.1. –
내가 The TCP/IP Guide site에서 복사 예를 들어 트레일러의 복사 여기 부분입니다. 
예고편에서 트레일러 헤더를 사용하려면 헤더 이름과 함께 예고편 : 헤더 _ 이름 헤더 필드를 추가 한 다음 청크 본문 영역 뒤에 예고편 헤더 요소를 추가해야합니다.
RFC 당 HTTP 본문에 0 개 이상의 트레일러 헤더를 추가 할 수 있습니다. 제 RFC7230 4.1.2 트레일러 헤더 영역에 다음과 같은 헤더의 사용을 금지 :
메시지 프레임 (예를 들어, 전송 인코딩 및 콘텐츠 길이의 필드에 필요한 포함 된 트레일러를 생성해서는 안 송신자) 라우팅 (예를 들어, 호스트), 요청 수정 (예를 들어, 제어 및 RFC7231 제 5 조건문), 인증 (예를 들어,) 응답 제어 데이터 RFC7235 및 RFC6265 (참조 예) 7.1 RFC7231의 참조 , 페이로드 처리 방법 결정 (예 : Content-Encoding, 콘텐츠 유형, 콘텐츠 범위 및 예고편).
이렇게하면 예고편 헤더 영역에 다른 표준 헤더와 맞춤 헤더를 사용할 수 있습니다.
사실,하지만 당신은 정말로 RFC 7230을 인용해야합니다. –
Julian. 방금 RFC 7230을 탐색하고 인용문을 업데이트했습니다. 청크 및 트레일러 부분의 경우 더 명확합니다. – appleleaf
게시 해 주셔서 감사합니다. 동일한 문제가 궁금합니다. 나를 던지는 것은 길이가 0 인 청크가 길이가 0 인 데이터 뒤에 자신의 \ r \ n이 없다는 것입니다. 이제는 RFC를 다시 읽었지만 분명히 헤더가 어떻게 보이는지에 대한 명확한 예를 보려면 좋았습니다 ... RFC에 RFC를 추가하기를 바랍니다. – eselk
Gzip으로 인코딩 된 스트림에서 청크 된 부분을 어떻게 감지합니까? –
@Alexsandro_xpt - 메시지 본문이 먼저 압축 된 다음 청크되어 있으므로 압축 해제하지 않고 청크 인코딩을 디코딩 할 수 있습니다. http://tools.ietf.org/html/rfc7230#section-3.3.1 –