Opened 4 years ago
Last modified 4 years ago
#2109 accepted defect
Content-Type header is dropped when HTTP2 is used( HTTP status 204 only)
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.18.x |
| Keywords: | http2 | Cc: | |
| uname -a: | Linux KONG 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.18.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --with-pcre-jit --with-ipv6 --with-http_realip_module --with-http_ssl_module --with-http_stub_status_module --with-http_v2_module --with-pcre --prefix=/opt/header_test |
||
Description
When backend server returned HTTP status 204 with Content-Type header.
The Content-Type header is set and sent correctly when using HTTP1.1(over plain-text HTTP or over HTTPS).
However, when making a request using HTTP2 (over TLS), that header is not sent.
I can't see a reason for this and would guess that this is a bug in Nginx. Or am I missing something?
Note:
See TracTickets
for help on using tickets.
It looks like a bug in
ngx_http_v2_header_filter(). In contrast tongx_http_header_filter(), it clearsr->headers_out.content_typenot only in case of nginx internal responses (that is, responses withoutr->headers_out.status_line), but in all cases, including proxied responses. This looks wrong, as 204 responses can have legitimate metadata headers.