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

Issue metadata

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

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
 
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