New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users
Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
RST_STREAM with NO_ERROR isn't handled properly
Reported by vb...@nginx.com, Apr 13 2016 Back to list
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
 
trace.txt
52.5 KB View Download
Comment 1 by b...@chromium.org, Apr 13 2016
Components: -Internals>Network Internals>Network>HTTP2
Owner: b...@chromium.org
Status: Assigned
Comment 2 by vb...@nginx.com, 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.
Comment 3 by b...@chromium.org, Apr 29 2016
Note that this might be related to issue 606990.
Comment 4 by b...@chromium.org, Sep 27 2016
 Issue 650438  has been merged into this issue.
Comment 5 by mef@chromium.org, Sep 27 2016
Cc: mxyan@google.com mef@chromium.org
Components: Internals>Network>Library
Labels: -OS-Linux OS-All
Comment 6 by mxyan@google.com, Sep 27 2016
Thanks mef@
Comment 7 by mxyan@google.com, Oct 10 2016
A slight poke on this issue; we are still looking forward to this fix :)
Comment 8 by mxyan@google.com, Oct 26 2016
Can we get an update on this issue?
Comment 9 by b...@chromium.org, Oct 26 2016
Yes, draft CL is at https://crrev.com/2445113002, that should solve it.
Comment 10 by mxyan@google.com, Oct 26 2016
Cool thanks!
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.
Comment 12 by b...@chromium.org, Nov 11 2016
Status: Fixed
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