- From: RFC Errata System <rfc-editor@rfc-editor.org>
- Date: Mon, 25 Dec 2017 01:55:24 -0800 (PST)
- To: fielding@gbiv.com, julian.reschke@greenbytes.de, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, mnot@mnot.net, pmcmanus@mozilla.com
- Cc: diogin@gmail.com, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
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/eid5216 -------------------------------------- Type: Technical Reported by: Jingcheng Zhang <diogin@gmail.com> Section: 5.4. Original Text ------------- A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field-value. Corrected Text -------------- A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a recipient MUST reject this request. Notes ----- First, If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component. Secondly, section 2.7.1 said: A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid. So a recipient MUST reject a request with empty authority. 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 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 Monday, 25 December 2017 09:55:59 UTC