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

Host and :authority must agree #968

Merged
merged 7 commits into from
Sep 24, 2021
Merged

Host and :authority must agree #968

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
2cfe2e9
Host and :authority must agree
martinthomson Sep 14, 2021
bad442d
Fix potentially ambiguous 'it'
martinthomson Sep 14, 2021
b4eec03
normalization; yuck
martinthomson Sep 14, 2021
6444758
Willy's edit to avoid a direct HTTP/1.1 dependency
martinthomson Sep 14, 2021
577a84a
Much appreciated Greg
martinthomson Sep 16, 2021
af9a402
no need for this extra stipulation
martinthomson Sep 16, 2021
ca28eef
generate
martinthomson Sep 24, 2021
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
26 changes: 23 additions & 3 deletions draft-ietf-httpbis-http2bis.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2934,16 +2934,33 @@ cookie: e=f
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>
Clients MUST NOT generate a request with a <tt>Host</tt> header field that differs
from the <tt>:authority</tt> pseudo-header field. A
server SHOULD treat a request as malformed if it contains a <tt>Host</tt> header
field that identifies a different entity to the <tt>:authority</tt> pseudo-header
field. The values of fields need to be normalized to compare them (see <xref
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does "of fields" apply to all fields, all pseudo fields or just :authority fields?

Does the normalization "need" apply to the byte-for-byte comparison above ie. do MUST they only be byte-for-byte identical after normalization?

Is a "need" a MUST or a SHOULD?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this instance, I think "need" is a statement of fact -- these are hostnames, therefore not case-sensitive, therefore they need to be normalized to perform a useful comparison. No need for RFC2119 language here. However, that implies that "when compared byte-for-byte" above is wrong.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're placing a stronger requirement on the sender than the receiver. The receiver requirements are more lax because we want to allow for folks like @icing who might want to avoid extra work to do so (either because they are happy that their h2 implementation is otherwise OK and don't want to open the patient to add extra checks that will mostly just slow them down). We don't need to see every server doing this rejection, just a few. Clients will learn not to put different values in.

That said, I think we can say "identical" in the first part without resorting to "byte-for-byte". "byte-for-byte" is just the most obvious and easiest way to ensure that the values are the same.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...we want to allow for folks like @icing who might want to avoid extra work to do so...

That's very kind and heart-warming.😌

target="RFC3986" section="6.2"/>). An origin server can apply any normalization
method, whereas other servers MUST perform scheme-based normalization (see <xref
target="RFC3986" section="6.2.3"/>) of the two fields.
</t>
<t>
An intermediary that forwards a request over HTTP/2 MUST construct an
<tt>:authority</tt> 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
<tt>:authority</tt>). Note that the Host header field is not the sole source of this
information; see <xref target="HTTP" section="7.2"/>.
<tt>:authority</tt>). Note that the <tt>Host</tt> header field is not the sole
source of this information; see <xref target="HTTP" section="7.2"/>.
</t>
<t>
An intermediary that needs to generate a <tt>Host</tt> header field (which might be
necessary to construct an HTTP/1.1 request) MUST use the value from the <tt>:authority</tt>
pseudo-header field as the value of the <tt>Host</tt> field,
unless the intermediary also changes the request target. This replaces any existing
<tt>Host</tt> field to avoid potential vulnerabilities in HTTP routing.
</t>
<t>
An intermediary that forwards a request over HTTP/2 MUST retain any <tt>Host</tt>
An intermediary that forwards a request over HTTP/2 MAY retain any <tt>Host</tt>
header field.
</t>
<t>
Expand Down Expand Up @@ -5172,6 +5189,9 @@ cookie: e=f
Connection-specific header fields - which are prohibited - are more precisely and
comprehensively identified.
</li>
<li>
<tt>Host</tt> and <tt>:authority</tt> are no longer permitted to disagree.
</li>
</ul>
</section>
<section numbered="false">
Expand Down