Issue metadata
Sign in to add a comment
|
Chromium parse header frame fail and cause net::ERR_SPDY_PROTOCOL_ERROR after HTTP2 enabled
Reported by
cangmi...@gmail.com,
Jul 25 2017
|
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Example URL:
Steps to reproduce the problem:
Only a few machine can reproduce this problem, and all have important data.
What is the expected behavior?
Chromium can parse header successfully and no reset frame send back to server.
What went wrong?
There is no error found in the header frame packet captured by wireshark.
But chromium parse the header frame fail and show "Could not parse Spdy Control Frame Header."
The HTTP2 event capture by chromium
t=6536 [st=6535] HTTP2_SESSION_SEND_RST_STREAM
--> description = "Could not parse Spdy Control Frame Header."
--> error_code = "1 (PROTOCOL_ERROR)"
--> stream_id = 655
The packet capture by wireshark
14553 66.717090554 10.12.7.161 10.12.4.37 HTTP2 1674 HEADERS, DATA
Frame 14553: 1674 bytes on wire (13392 bits), 1674 bytes captured (13392 bits) on interface 0
Ethernet II, Src: Synology_3a:79:70 (00:11:32:3a:79:70), Dst: AsustekC_34:49:1c (78:24:af:34:49:1c)
Internet Protocol Version 4, Src: 10.12.7.161, Dst: 10.12.4.37
Transmission Control Protocol, Src Port: 443, Dst Port: 11603, Seq: 19630295, Ack: 53961, Len: 1608
Secure Sockets Layer
HyperText Transfer Protocol 2
Stream: HEADERS, Stream ID: 655, Length 214
Length: 214
Type: HEADERS (1)
Flags: 0x04
.... ...0 = End Stream: False
.... .1.. = End Headers: True
.... 0... = Padded: False
..0. .... = Priority: False
00.0 ..0. = Unused: 0x00
0... .... .... .... .... .... .... .... = Reserved: 0x0
.000 0000 0000 0000 0000 0010 1000 1111 = Stream Identifier: 655
[Pad Length: 0]
Header Block Fragment: 887684aa6355e76196df697e94136a65b6850400baa01db8...
[Header Length: 365]
[Header Count: 10]
Header: :status: 200
Header: server: nginx
Header: date: Tue, 25 Jul 2017 07:32:18 GMT
Header: content-type: application/json; charset="UTF-8"
Header: can_export[31812]: backup framework version = 2.0
Header: x-content-type-options: nosniff
Header: x-xss-protection: 1; mode=block
Header: cache-control: max-age=0, no-cache, no-store, must-revalidate
Header: pragma: no-cache
Header: expires: 0
Padding: <MISSING>
Stream: DATA, Stream ID: 655, Length 1347
Length: 1347
Type: DATA (0)
Flags: 0x00
.... ...0 = End Stream: False
.... 0... = Padded: False
0000 .00. = Unused: 0x00
0... .... .... .... .... .... .... .... = Reserved: 0x0
.000 0000 0000 0000 0000 0010 1000 1111 = Stream Identifier: 655
[Pad Length: 0]
Data: 7b2264617461223a5b7b22646570656e64223a7b22736861...
Padding: <MISSING>
Did this work before? Yes 55
Chrome version: 59.0.3071.115 Channel: stable
OS Version: 3.13.0-37
Flash Version:
,
Jul 26 2017
According to RFC7230 Section 3.2, '[' and ']' are not valid characters in a header field. Therefore Chrome signals an error on the response header field "can_export[31812]: backup framework version = 2.0". This is working as intended. Please contact the server administrator to change response headers so that there are no invalid characters in the header field.
,
Jul 26 2017
Sorry for bothering. I found the issue is caused by the header. can_export[31812]: backup framework version = 2.0 After I checked chromium source code, I found chromium take '[' and ']' as illegal header character. And the relative commit hash is 21b64f4da which is committed on Tue Feb 28 15:49:20 2017. Therefore, the problem only happens in latest chromium version. Thanks a lot. You may close this issue. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by mmenke@chromium.org
, Jul 25 2017