Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial suggestion #961

Merged
merged 1 commit into from
Sep 6, 2021
Merged

Editorial suggestion #961

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 19 additions & 26 deletions draft-ietf-httpbis-http2bis.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2903,42 +2903,35 @@ cookie: e=f
</li>
<li>
<t>
The <tt>:authority</tt> pseudo-header field includes the
authority portion of the target URI (<xref target="RFC3986" section="3.2"/>). The
authority MUST NOT include the deprecated <tt>userinfo</tt> subcomponent for
<tt>http</tt> or <tt>https</tt> schemed URIs.
The <tt>:authority</tt> pseudo-header field conveys the authority portion (<xref
target="RFC3986" section="3.2"/>) of the target URI (<xref target="HTTP"
section="7.1"/>). The recipient of a HTTP/2 request MUST ignore the Host header
field if :authority is present.
</t>
<t>
Clients that generate HTTP/2 requests directly SHOULD use the <tt>:authority</tt>
pseudo-header field instead of the <tt>Host</tt> header field.
Clients that generate HTTP/2 requests directly MUST use the :authority
pseudo-header field to convey authority information, unless there is no authority
information to convey (in which case it MUST NOT generate :authority).
</t>
<t>
An intermediary that forwards a request to HTTP/2 MUST construct an
<tt>:authority</tt> pseudo-header field using the authority information from the
control data in the original request. If control data does not contain authority,
an intermediary MUST NOT add an <tt>:authority</tt> pseudo-header field. Note that
while the <tt>Host</tt> header field can determine a request target, it is not
control data for this purpose; see <xref target="HTTP" section="7.2"/>.
An intermediary that forwards a request over HTTP/2 MUST construct an :authority
pseudo-header field using the authority information from the control data of the
original request, unless the the original request's target URI does not contain
authority information (in which case it MUST NOT generate :authority). Note that
the Host header field is not the sole source of this information; see <xref
target="HTTP" section="7.2"/>.
</t>
<t>
Request targets for CONNECT or asterisk-form OPTIONS requests do not include
authority.
An intermediary that forwards a request over HTTP/2 MUST retain any Host header
field.
</t>
<t>
An intermediary that forwards from HTTP/2 can construct a <tt>Host</tt> header field
by copying the value of the <tt>:authority</tt> pseudo-header field. This might be
necessary if that version requires that <tt>Host</tt> be included in a request, as
HTTP/1.1 does for some forms of request target (see <xref target="HTTP11"
section="3.2"/>).
Note that request targets for CONNECT or asterisk-form OPTIONS requests never
include authority information.
</t>
<t>
An intermediary that forwards a request to HTTP/2 MUST retain any <tt>Host</tt>
header field, even if an authority is part of control data.
</t>
<t>
The value of the <tt>Host</tt> header field MUST be ignored if control data
contains authority (that is, the <tt>:authority</tt> pseudo-header field is
present).
:authority MUST NOT include the deprecated userinfo subcomponent for http or https
schemed URIs.
</t>
</li>
<li>
Expand Down