- From: RFC Errata System <rfc-editor@rfc-editor.org>
- Date: Wed, 13 Apr 2016 03:45:00 -0700 (PDT)
- To: fielding@gbiv.com, ylafon@w3.org, julian.reschke@greenbytes.de, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, mnot@mnot.net
- Cc: amichai2@amichais.net, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
The following errata report has been submitted for RFC7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4665 -------------------------------------- Type: Technical Reported by: Amichai Rothman <amichai2@amichais.net> Section: 3.1 Original Text ------------- Corrected Text -------------- If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response. Notes ----- An empty representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. An empty 200 response is the simplest solution to this contradiction, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations. 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. -------------------------------------- RFC7233 (draft-ietf-httpbis-p5-range-26) -------------------------------------- Title : Hypertext Transfer Protocol (HTTP/1.1): Range Requests Publication Date : June 2014 Author(s) : R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed. Category : PROPOSED STANDARD Source : Hypertext Transfer Protocol Bis APP Area : Applications Stream : IETF Verifying Party : IESG
Received on Wednesday, 13 April 2016 10:45:46 UTC