RST_STREAM with NO_ERROR isn't handled properly
Reported by
vb...@nginx.com,
Apr 13 2016
|
|||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Example URL:
Steps to reproduce the problem:
1. Install nginx 1.9.14 and configure simple HTTP/2 server:
events {}
http {
ssl_certificate cert.pem;
ssl_certificate_key key.pem;
server {
listen 4433 ssl http2;
location / { }
}
}
2. Make a POST request with non-empty body to any static file (index.html for example);
3. Instead of "405 Not Allowed" error page you will see a blank one.
What is the expected behavior?
RFC 7540 states that "A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag)."
What went wrong?
According to Chromium "net-internals" the RST_STREAM frame with the NO_ERROR code is interpreted as INTERNAL_ERROR, which is very wrong. That prevents Chromium from showing any response from nginx that has been returned without reading the full request body.
Did this work before? No
Chrome version: 50.0.2661.66 (Developer Build) (64-bit) Channel: n/a
OS Version:
Flash Version: Shockwave Flash 11.2 r202
Firefox handles it without any problems.
Initially reported to nginx-devel@ mailing list:
http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008143.html
,
Apr 14 2016
I've committed a workaround for nginx: http://hg.nginx.org/nginx/rev/8df664ebe037 I hope this issue will be fixed soon and we will be able to backout the workaround after a while.
,
Apr 29 2016
Note that this might be related to issue 606990.
,
Sep 27 2016
Issue 650438 has been merged into this issue.
,
Sep 27 2016
,
Sep 27 2016
Thanks mef@
,
Oct 10 2016
A slight poke on this issue; we are still looking forward to this fix :)
,
Oct 26 2016
Can we get an update on this issue?
,
Oct 26 2016
Yes, draft CL is at https://crrev.com/2445113002, that should solve it.
,
Oct 26 2016
Cool thanks!
,
Oct 28 2016
Patch for this landed in Chromium, but the commit message missed this BUG, so it wasn't updated: https://chromium.googlesource.com/chromium/src/+/c22b581e818b5371b217aa0b8a6758560138bede It's part of M56, so it's going to hit stable channel around Jan 31st, 2017.
,
Nov 11 2016
The CL mentioned in #11 should fix the Chromium network part of this bug, so I'm closing this issue. See issue 650438 and the CL referencing that for the Cronet side fix. |
|||
►
Sign in to add a comment |
|||
Comment 1 by b...@chromium.org
, Apr 13 2016Owner: b...@chromium.org
Status: Assigned (was: Unconfirmed)