x/net/http2: does not conform to RFC strictly

[changlidong]

I builded a HTTP2 Server Demo by x/net/http2 of Golang and found some behaviors that does not conform to RFC7540 strictly. I’d like to separate it into four categories: Wrong ErrorCode, Wrong ErrorType, WrongFrame and Ignoring.

• Wrong ErrorCode
  this means client receives an unExpected ErrorCode from the server according to the rfc.
  e.g. when an endpoint receives a HEADERS Frame when the stream is in half closed (remote) state, the server response a stream error of code PROTOCOL_ERROR. While rfc has said that "it MUST respond with a stream error of code STREAM_CLOSED"(rfc 7540, section 5.1).
• Wrong ErrorType
  this means the server is expected to response a connection error, but actually it responses a stream error instead, or vice versa.
  e.g. when sending a DATA Frame in a stream that is in idle state, the server responds with an RST_STREAM. while rfc has ruled that "it MUST treat it as a connection error of type PROTOCOL_ERROR"(rfc 7540, section 5.1).
• Wrong Frame
  this is the case that when sending a HEADERS frame that contains the connection-specific header field, we expect to receive a RST_STREAM Frame from server, because rfc has ruled that "An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed"(rfc 7540, section 8.1.2.2) and "Malformed requests or responses that are detected MUST be treated as a stream error of type PROTOCOL_ERROR"(rfc 7540, section 8.1.2.6). but actually the client receives a DATA frame, the payload of which is "request header "Connection" is not valid in HTTP/2”.
• Ignoring
  this means that the server seems to ignore some frames under certain conditions. for example, when sending a Headers Frame that depend on itself , the server does not seems to be affected and responds with a normal DATA Frame. while rfc has said that "A stream cannot depend on itself. An endpoint MUST treat this as a stream error of type PROTOCOL_ERROR"(rfc 7540, section 5.3.1).

all case code can be found from here.
one more question, any plans to fix these problems in the near future?

[gopherbot]

CL https://golang.org/cl/31736 mentions this issue.

[gopherbot]

CL https://golang.org/cl/31858 mentions this issue.

[bradfitz]

Wrong ErrorCode

If an endpoint receives additional frames, other than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED.

But the spec on HEADERS says otherwise, which we implement:

        // [...] The identifier of a newly established stream MUST be
    // numerically greater than all streams that the initiating
    // endpoint has opened or reserved. [...]  An endpoint that
    // receives an unexpected stream identifier MUST respond with
    // a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
    if id <= sc.maxStreamID {
        return ConnectionError(ErrCodeProtocol)
    }

In any case, please file a separate bug about this. Many small, independent bugs are easier than one big bug.

Wrong ErrorType

this means the server is expected to response a connection error, but actually it responses a stream error instead, or vice versa.
e.g. when sending a DATA Frame in a stream that is in idle state, the server responds with an RST_STREAM. while rfc has ruled that "it MUST treat it as a connection error of type PROTOCOL_ERROR"(rfc 7540, section 5.1).

Fixed by 41c5c5cb12965112d2e298342c73e6b3e045a14a

Wrong Frame

"An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed"(rfc 7540, section 8.1.2.2) and "Malformed requests or responses that are detected MUST be treated as a stream error of type PROTOCOL_ERROR"(rfc 7540, section 8.1.2.6). but actually the client receives a DATA frame, the payload of which is "request header "Connection" is not valid in HTTP/2”.

Hmm, the GFE does it the way we do. As long as we reject it, it seems
non-critical. I'll ask the GFE team why they did what they did.

Ignoring

A stream cannot depend on itself. An endpoint MUST treat this as a stream error of type PROTOCOL_ERROR"(rfc 7540, section 5.3.1)."

Fixed by 65dfc08770ce66f74becfdff5f8ab01caef4e946

I'm going to close this bug for now.

Please file separate bugs for anything else you find. Again, I'd prefer many small bugs instead of 1 big bug with separate issues.

Thanks!

[changlidong]

sorry about that. I'll deal with it these days. much appreciate your work