You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In 8.1.2.3 there is a test that "sends a HEADERS frame with empty ":path" pseudo-header field" expecting that the server responds with a PROTOCOL_ERROR.
I do not think that RFC 7540 requires such behavior.
Section 8.1.2.3 states:
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'. The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*' (see [RFC7230], Section 5.3.4).
All HTTP/2 requests MUST include exactly one valid value for the
":method", ":scheme", and ":path" pseudo-header fields, unless it is
a CONNECT request (Section 8.3). An HTTP request that omits
mandatory pseudo-header fields is malformed (Section 8.1.2.6).
As you can see from the last paragraph, a server is required to respond with a malformed error (i.e. PROTOCOL_ERROR) if the pseudo header field is omitted. There is no definition regarding how a server responds to a request with an empty :path pseudo header field, even though such field is prohibited in the previous paragraph.
Therefore I think that a server is permitted to respond in other ways than sending a PROTOCOL_ERROR (e.g. respond with a 400 Bad Request).
The text was updated successfully, but these errors were encountered:
In 8.1.2.3 there is a test that "sends a HEADERS frame with empty ":path" pseudo-header field" expecting that the server responds with a PROTOCOL_ERROR.
I do not think that RFC 7540 requires such behavior.
Section 8.1.2.3 states:
As you can see from the last paragraph, a server is required to respond with a malformed error (i.e.
PROTOCOL_ERROR
) if the pseudo header field is omitted. There is no definition regarding how a server responds to a request with an empty:path
pseudo header field, even though such field is prohibited in the previous paragraph.Therefore I think that a server is permitted to respond in other ways than sending a
PROTOCOL_ERROR
(e.g. respond with a 400 Bad Request).The text was updated successfully, but these errors were encountered: