Note: Related to Issue 797825 , but I didn't want to make this block on it or block it, since it's distinct enough to be its own issue.
Currently, the HTTP/2 and QUIC code uses QuicUrlUtils::IsValidUrl(), QuicUrlUtils::HostName(), and SpdyUtils::GetUrlFromHeadersBlock to handle processing of responses (and notably, PUSH_PROMISES)
The HTTP/2 RFC makes several remarks re: client/server behaviour, namely:
https://tools.ietf.org/html/rfc7540#section-8.1.2.3
":authority" MUST be present, MAY be empty (by virtue of a 'host' that is a 'reg-name' which is allowed to be 0 characters by virtue of https://tools.ietf.org/html/rfc3986#section-3.2.2 ) , and MUST NOT contain the "userinfo" component of the authority
- Notably, unless the scheme defines a default host, then the host portion of the authority MUST NOT be empty - namely "whereas the "http" scheme considers a missing authority or empty host invalid."
A current gap within SpdyUtils::GetUrlFromHeadersBlock() is that it does not enforce the invariant regarding 'userinfo'. It returns a (potentially invalid) URL, which then implementations like QuicUrlUtils::IsValidUrl() and QuicUrlUtils::HostName() attempt to parse into a GURL (forcing canonicalization each time they do, which is not ideal), without enforcing that the userinfo is empty.
Separately, the :path component MAY be "*" in the case of an OPTIONS request, but I couldn't find any code that validated the path / checked the '*' (although perhaps I missed it)
Comment 1 by sheriffbot@chromium.org
, Jan 14Status: Untriaged (was: Available)