New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 603182 link

Starred by 10 users

Issue metadata

Status: Fixed
Last visit 22 days ago
Closed: Nov 2016
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, 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:
52.5 KB View Download

Comment 1 by, Apr 13 2016

Components: -Internals>Network Internals>Network>HTTP2
Status: Assigned (was: Unconfirmed)

Comment 2 by, Apr 14 2016

I've committed a workaround for nginx:

I hope this issue will be fixed soon and we will be able to backout the workaround after a while.

Comment 3 by, Apr 29 2016

Note that this might be related to issue 606990.

Comment 4 by, Sep 27 2016

 Issue 650438  has been merged into this issue.

Comment 5 by, Sep 27 2016

Components: Internals>Network>Library
Labels: -OS-Linux OS-All

Comment 6 by, Sep 27 2016

Thanks mef@

Comment 7 by, Oct 10 2016

A slight poke on this issue; we are still looking forward to this fix :)

Comment 8 by, Oct 26 2016

Can we get an update on this issue?

Comment 9 by, Oct 26 2016

Yes, draft CL is at, that should solve it.

Comment 10 by, Oct 26 2016

Cool thanks!
Patch for this landed in Chromium, but the commit message missed this BUG, so it wasn't updated:

It's part of M56, so it's going to hit stable channel around Jan 31st, 2017.

Comment 12 by, Nov 11 2016

Status: Fixed (was: Assigned)
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