Opened 6 years ago
Closed 6 years ago
Last modified 6 years ago
#1351 closed defect (worksforme)
NGINX closing connection with GOAWAY if client sends SETTINGS_MAX_HEADER_LIST_SIZE with too large value in initial SETTINGS frame
|Reported by:||Owned by:|
Experienced between Chrome 62.0.3167.0 and above and https://www.123-reg.co.uk, which runs NGINX according to the response headers but I am not able to determine the version. Please contact the site administrator for more information.
If the client does not send a SETTINGS_MAX_HEADER_LIST_SIZE field in the initial settings frame, or sends one with value less than or equal to 32768, then the request succeeds.
If the client sends a SETTINGS_MAX_HEADER_LIST_SIZE value greater than 32768, then NGINX responds with a GOAWAY frame with last_accepted_stream_id = 0, error_code = NO_ERROR, and no debug data.
This, however, does not make sense: the client sending a SETTINGS_MAX_HEADER_LIST_SIZE value tells the server how long response headers the client is willing to accept at maximum. Larger value means the client is willing to accept larger responses. It does not ask or require the server to use more memory.
See https://crbug.com/751642 for Chrome bug.
Change History (2)
comment:1 by , 6 years ago
|Status:||new → closed|
comment:2 by , 6 years ago
Thank you for investigating. I believe you are right guessing that some proxy is involved: looking at comments at https://crbug.com/751642, it seems like the issue is caused by a load balancer middlebox.
It doesn't make any sense, because nginx doesn't process SETTINGS_MAX_HEADER_LIST_SIZE value at all. The value just ignored by nginx since the initial commit of HTTP/2 implementation.
We've tested with all currently supported versions of nginx and can't reproduce.
I guess, something else is involved there: 3-rd party patches, or some proxy in front of nginx.