Re: [Technical Errata Reported] RFC7230 (4412)

Reject; these are two separate requirements, on responses and requests, respectively.

Sent from my iPhone

> On 9 Jul 2015, at 6:44 pm, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7230,
> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4412
> 
> --------------------------------------
> Type: Technical
> Reported by: Rick Taylor <rick@tropicalstormsoftware.com>
> 
> Section: 3.3.3
> 
> Original Text
> -------------
> 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.
> 
> Corrected Text
> --------------
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
> --------------------------------------
> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
> Publication Date    : June 2014
> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
>

Received on Thursday, 9 July 2015 10:54:16 UTC