HTTP2 headers compatibility with older browsers

Question

I heard today that soon the http2 protocol will be implemented in modern browsers. More information: https://en.wikipedia.org/wiki/HTTP/2, I know wikipedia is not the best resource, but it will give a little clue about what is going on. The question is:

---

How will old browsers respond to http2 headers?

I mean on php (http://php.net) there is still (26.02.2015) a link in header function (http://php.net/manual/en/function.header.php) to the http1.1 specification (http://www.faqs.org/rfcs/rfc2616). I understand that in http2 all I must do is change header from for example HTTP/1.1 404 Not Found to something similar to HTTP/2.0 404 Not Found. But how will older browsers respond to it? Is this transparent for webdevelopers, and php coders, and implemented on browser / server side, or there are some important things / clues about compatibility?

Is using http2 headers right after they are ready a good idea?

I don't want to hurt anyone, but I know such a browser that it first name starts on the leter I, and second with the letter E, that can always mess up a little. I'm afraid that the new specification will totally ruined all older version of this browser, and that this http2. And we - developers must write websites that just work, no matter where, and the magic http2 will come true after milions tons of patches / upgrades / months of compatibility problems with older machines.

---

There must be some code in well formed question, so here it is :):

<?php
    header("HTTP/2.0 404 Not Found"); // Am I correct? It will look like this?
?>

What about old browsers in this case?

Is this a good idea to use it right after http2 is alive?

---

Additional documentation:

1. Draft http2 specification: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-17
2. Wikipedia few words: https://en.wikipedia.org/wiki/HTTP/2
3. PHP header function: http://php.net/manual/en/function.header.php
4. W3.org about http2: http://www.w3.org/Protocols/HTTP/HTTP2.html

Answer 1

In a typical scenario, a HTTP/2-capable client contacting a server does so using a HTTP/1.1 connection initially, using the Upgrade: header to indicate the availability of HTTP/2 support.

This looks something like this:

 GET / HTTP/1.1
 Host: server.example.com
 Connection: Upgrade, HTTP2-Settings
 Upgrade: h2c
 HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

Source: HTTP/2 draft 17, Sec 3.2

I'm quoting the specs directly there, so a real request from a real client would look slightly more complex – it would include the usual HTTP/1.1 headers as well, such that a server not wishing to upgrade to HTTP/2 could simply continue with the request. A server not supporting HTTP/2 simply ignores the Upgrade: h2c and HTTP2-Settings: ... headers.

Servers upgrading the connection to HTTP/2 respond with:

 HTTP/1.1 101 Switching Protocols
 Connection: Upgrade
 Upgrade: h2c
  
 PRI * HTTP/2.0
  
 SM
  
  

Source: HTTP/2 draft 17, Sec 3.2

That section starting PRI * is called the 'client connection preface' and is sent at the start of any HTTP/2 connection. It is designed to be a string that no HTTP/1.0 or /1.1 server would respond to. That means that even in the non-typical scenario where a browser has reason to believe a server supports HTTP/2 before connecting (we're talking maybe an intranet environment with service advertisement via other protocols, for instance), the HTTP/2 client would open a connection with "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" and be immediately rejected with a HTTP/1.1 400 Bad Request by any HTTP/1.X server. (A client might then downgrade the request to HTTP/1.1 and continue, for instance.)

Rewriting PHP applications to directly use HTTP/2 is going to take a fair bit more work than changing header('HTTP/X.X...') numbers. Saikyr is right, HTTP/2 is a binary protocol; this means that we'll be using a new library to write HTTP/2 directly from PHP.

The sending of status code and message along with protocol version no longer occurs. Instead, pseudo-headers are used – basically just headers with a : in front to ensure no clash with HTTP/1.X headers. However headers aren't going to be sent in cleartext – a compression scheme has been drawn up for converting headers to binary codes. HPACK draft 12. (I haven't read it; it's less of a page-turner than HTTP/2.)

So instead of header("HTTP/2 404 Not Found"); you'll do something like this:

 \HTTP2::setHeader(':status','404'); 

or instead of header("Location: $PROTO://$HOST$PATH");

 \HTTP2::setHeader('location', "$PROTO://$HOST$PATH"); 

I'm not aware of such support in PHP yet, so I'm guessing a bit there. I'm not certain whether PHP could gain enough control of an Apache connection to upgrade from HTTP/2 and manage the connection itself. As support is added to Apache there might be opportunity for PHP to link in at the library level. Whatever the new library, it might still be capable of writing the headers of a HTTP/1.1 connection, depending on the client – but it is going to require rewriting software, unless they decide to have header() re-parse each argument for HTTP/2 output (which is not inconceivable but seems to me like it would cause more problems than it would solve).

One way in which HTTP/2 support could be added would be at the server/transport level, with some translation of HTTP/1.1 headers into HTTP/2. An Apache module could conceivably parse HTML output and detect linked stylesheets, scripts and images, generating PUSH_PROMISEs to the client when responding to a GET request.

The primary advantage to supporting HTTP/2 directly in PHP would be allowing the resources linked to to be 'pushed' to willing clients who support the feature. Many PHP-based CMS environments would be able to supply a list of stylesheets, scripts and images without having to re-parse output intended for the client.

I'm looking forward to seeing what we can do!