4. HTTP Frames
4.2. Frame Size
× 1: Sends a DATA frame with 2^14 octets in length
-> The endpoint MUST be capable of receiving and minimally processing frames up to 2^14 octets in length.
Expected: HEADERS Frame (stream_id:1)
Actual: Connection closed
Comment: Error in h2spec - DATA payload size didn't equal the value of "content-length" header.
5. Streams and Multiplexing
5.1. Stream States
5.1.2. Stream Concurrency
× 1: Sends HEADERS frames that causes their advertised concurrent stream limit to be exceeded
-> The endpoint MUST treat this as a stream error of type PROTOCOL_ERROR or REFUSED_STREAM.
Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR)
RST_STREAM Frame (Error Code: PROTOCOL_ERROR)
GOAWAY Frame (Error Code: REFUSED_STREAM)
RST_STREAM Frame (Error Code: REFUSED_STREAM)
Connection closed
Actual: DATA Frame (length:845, flags:0x01, stream_id:201)
Comment: Ambiguous testing algorithm in h2spec. Streams quickly snatched up by worker threads
5.5. Extending HTTP/2
× 2: Sends an unknown extension frame in the middle of a header block
-> The endpoint MUST treat as a connection error of type PROTOCOL_ERROR.
Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR)
Connection closed
Actual: Timeout
Comment: I didn't find any references in RFC 7540 that unknown extension frame in the middle
of a header block should cause a connection error
6. Frame Definitions
6.5. SETTINGS
6.5.3. Settings Synchronization
× 1: Sends multiple values of SETTINGS_INITIAL_WINDOW_SIZE
-> The endpoint MUST process the values in the settings in the order they apper.
Expected: DATA Frame (length:1, flags:0x00, stream_id:1)
Actual: DATA Frame (length:845, flags:0x01, stream_id:1)
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
6.9. WINDOW_UPDATE
6.9.1. The Flow-Control Window
× 1: Sends SETTINGS frame to set the initial window size to 1 and sends HEADERS frame
-> The endpoint MUST NOT send a flow-controlled frame with a length that exceeds the space available.
Expected: DATA Frame (length:1, flags:0x00, stream_id:1)
Actual: DATA Frame (length:845, flags:0x01, stream_id:1)
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
× 2: Sends multiple WINDOW_UPDATE frames increasing the flow control window to above 2^31-1
-> The endpoint MUST sends a GOAWAY frame with a FLOW_CONTROL_ERROR code.
Expected: GOAWAY Frame (Error Code: FLOW_CONTROL_ERROR)
Actual: Timeout
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
× 3: Sends multiple WINDOW_UPDATE frames increasing the flow control window to above 2^31-1 on a stream
-> The endpoint MUST sends a RST_STREAM frame with a FLOW_CONTROL_ERROR code.
Expected: RST_STREAM Frame (Error Code: FLOW_CONTROL_ERROR)
Actual: Timeout
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
6.9.2. Initial Flow-Control Window Size
× 1: Changes SETTINGS_INITIAL_WINDOW_SIZE after sending HEADERS frame
-> The endpoint MUST adjust the size of all stream flow-control windows.
Expected: DATA Frame (length:1, flags:0x00, stream_id:1)
Actual: DATA Frame (length:845, flags:0x01, stream_id:1)
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
× 2: Sends a SETTINGS frame for window size to be negative
-> The endpoint MUST track the negative flow-control window.
Expected: DATA Frame (length:1, flags:0x00, stream_id:1)
Actual: Timeout
Comment: Agreed. I working to fix this. My problem - i don't clearly understand the WINDOW_UPDATE mechanism.
8. HTTP Message Exchanges
8.1. HTTP Request/Response Exchange
8.1.2. HTTP Header Fields
8.1.2.2. Connection-Specific Header Fields
× 1: Sends a HEADERS frame that contains the connection-specific header field
-> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR.
Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR)
RST_STREAM Frame (Error Code: PROTOCOL_ERROR)
Connection closed
Actual: DATA Frame (length:845, flags:0x01, stream_id:1)
Comment: I know that this violates the requirements of RFC 7540, but I sincerely consider them
redundant and the type of reaction to the header value should remain on the server side