should not expect PROTOCOL_ERROR in response to an empty `:path` pseudo header

[kazuho]

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).

[kazuho]

relates to: #85