CARVIEW |
Select Language
HTTP/2 200
date: Tue, 15 Jul 2025 02:26:29 GMT
content-type: text/html; charset=UTF-8
content-encoding: gzip
set-cookie: PHPSESSID=916h2b2e0e9cj3imec7d6pu4us; path=/
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
vary: Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 95f5d0b05819c19a-BLR
alt-svc: h3=":443"; ma=86400
RFC Errata Report » RFC Editor
Search RFCs
The Series
For Authors
Sponsor
RFC Errata
RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014
Note: This RFC has been obsoleted by RFC 9110, RFC 9112
Note: This RFC has been updated by RFC 8615
Source of RFC: httpbis (wit)
Errata ID: 4412
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick Taylor
Date Reported: 2015-07-09
Rejected by: Barry Leiba
Date Rejected: 2015-07-09
Section 3.3.3 says:
If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
It should say:
Either: If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. Or: If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
Notes:
The paragraph has two apparently contradictory rules. It is unclear which is the correct behaviour.
--VERIFIER NOTES--
They're not contradictory: the first is for responses and the second is for requests, which are different situations.
IAB • IANA • IETF • IRTF • ISE • ISOC • IETF Trust
Reports • Privacy Statement • Site Map • Contact Us