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

[Lukasa]

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]

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.

[mkauf]

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