New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent response header representation for HTTP/1.1 vs HTTP/2 #797
Comments
Some extra notes: Obviously some deviation from the standard representation is expected from HTTP/1.1 and HTTP/2. Most obviously, the version number will be different, as will header case (HTTP/2 implementations uniformly downcase their headers). However, curl clearly makes some effort to represent the HTTP/2 message as a HTTP/1.1-style message, as shown by the My suggestion is therefore that curl should insert a single space between the header name and value for HTTP/2 headers. |
curl's representation of HTTP/2 responses involves transforming the response to a format that is similar to HTTP/1.1. Prior to this change, curl would do this by separating header names and values with only a colon, without introducing a space after the colon. While this is technically a valid way to represent a HTTP/1.1 header block, it is much more common to see a space following the colon. This change introduces that space, to ensure that incautious tools are safely able to parse the header block. This also ensures that the difference between the HTTP/1.1 and HTTP/2 response layout is as minimal as possible. Bug: curl#797
curl's representation of HTTP/2 responses involves transforming the response to a format that is similar to HTTP/1.1. Prior to this change, curl would do this by separating header names and values with only a colon, without introducing a space after the colon. While this is technically a valid way to represent a HTTP/1.1 header block, it is much more common to see a space following the colon. This change introduces that space, to ensure that incautious tools are safely able to parse the header block. This also ensures that the difference between the HTTP/1.1 and HTTP/2 response layout is as minimal as possible. Bug: curl#797
Because the space is missing after the colon? I disagree. It's allowed to omit the space in HTTP 1.x. But of course libcurl could add the space to make the headers look more similar to HTTP 1.x headers. Apache's mod_http2 even converts the header names to camel case (e.g. "content-length" --> "Content-Length") |
Summary
When asking curl to print the HTTP headers (either by using
-v
or-I
), the representation of the response headers is different for HTTP/1.1 responses and for HTTP/2 responses. In particular, the HTTP/2 representation would not be parsed by a very strict HTTP/1.1 header block parser.I did this
curl --http1.1 -I https://http2bin.org/get
and
curl --http2 -I https://http2bin.org/get
(The only difference is
--http1.1
vs--http2
.)I expected the following
The same representation of the output from both commands.
I got
From HTTP/1.1:
From HTTP/2:
(Note the lack of spaces after the colons in the HTTP/2 representation.)
curl/libcurl version
curl 7.48.0 (x86_64-apple-darwin15.4.0) libcurl/7.48.0 OpenSSL/1.0.2g zlib/1.2.5 nghttp2/1.9.2
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets
operating system
Mac OS X El Capitan 10.11.5 Beta (15F31a)
The text was updated successfully, but these errors were encountered: