Re: [Technical Errata Reported] RFC7230 (5216)

Reject. A target URI can be any URI scheme.

....Roy


> On Dec 25, 2017, at 1:55 AM, 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/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 22:22:54 UTC