Skip to content
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

Closed
Lukasa opened this issue May 11, 2016 · 2 comments
Closed

Inconsistent response header representation for HTTP/1.1 vs HTTP/2 #797

Lukasa opened this issue May 11, 2016 · 2 comments
Labels

Comments

@Lukasa
Copy link
Contributor

Lukasa commented May 11, 2016

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:

HTTP/1.1 200 OK
Date: Wed, 11 May 2016 10:51:41 GMT
Server: h2o/1.7.0
Connection: keep-alive
Content-Length: 253
content-type: application/json
access-control-allow-origin: *
access-control-allow-credentials: true
x-clacks-overhead: GNU Terry Pratchett

From HTTP/2:

HTTP/2.0 200
server:h2o/1.7.0
date:Wed, 11 May 2016 10:51:37 GMT
content-type:application/json
access-control-allow-origin:*
access-control-allow-credentials:true
x-clacks-overhead:GNU Terry Pratchett
content-length:251

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

@Lukasa
Copy link
Contributor Author

Lukasa commented May 11, 2016

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 HTTP/2.0 string in the output response: HTTP/2 is rarely ever called HTTP/2.0.

My suggestion is therefore that curl should insert a single space between the header name and value for HTTP/2 headers.

Lukasa added a commit to Lukasa/curl that referenced this issue May 11, 2016
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
@jay jay added the HTTP/2 label May 11, 2016
Lukasa added a commit to Lukasa/curl that referenced this issue May 11, 2016
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
@mkauf
Copy link
Contributor

mkauf commented May 11, 2016

In particular, the HTTP/2 representation would not be parsed by a very strict HTTP/1.1 header block parser.

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

@bagder bagder closed this as completed in 0761a51 May 12, 2016
@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

3 participants