Opened 7 years ago

Closed 7 years ago

Last modified 7 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: bencebeky@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.13.x
Keywords: Cc:
uname -a:
nginx -V: N/A


Experienced between Chrome 62.0.3167.0 and above and, 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 for Chrome bug.

Change History (2)

comment:1 by Valentin V. Bartenev, 7 years ago

Resolution: worksforme
Status: newclosed

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.

comment:2 by bencebeky@…, 7 years ago

Thank you for investigating. I believe you are right guessing that some proxy is involved: looking at comments at, it seems like the issue is caused by a load balancer middlebox.

Note: See TracTickets for help on using tickets.