Questions
- Do I have to look at response headers like
X-Firefox-Spdyto determine which protocol was actually used? - Can I assume that Nginx will report HTTP/2 status codes once the implementation is finalized because that is to be expected behaviour or is there something about status codes I don't know?
Information found by composing this question:
- Nginx ignoring client's HTTP 1.0 request and respond by HTTP 1.1
- Apache with SPDY enabled show HTTP/1.1 and not 2.0
Investigation and details
I'm currently examining my server setup and I'm a bit confused about the http status codes I see in the developer console of my browser.
My server runs Ubuntu 14.04 with an updated version of Nginx (PPA). Nginx is configured to use SPDY and a self signed certificate. I think SPDY is configured properly since Qualys SSL Labs test reported that the server offers SPDY 3.1 (and of course there are a plethora of browser plugins), but is HTTP/1.1 200 correct?
Here is the complete request from my server:
Request-URL: https://myserver/lib/dojo/something.js?123456789
Request-Methode: GET
Status-Code: HTTP/1.1 200 OK
Request-Header 13:50:30.000
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Referer: https://myserver/index.php
Pragma: no-cache
Host: myserver
DNT: 1
Connection: keep-alive
Cache-Control: no-cache
Accept-Language: de-DE,en-US;q=0.8,de;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept: */*
Sent Cookie
-xxx-
Response-Header Δ1ms
X-Firefox-Spdy: 3.1
Strict-Transport-Security: max-age=15768000; includeSubDomains
Server: nginx/1.9.3
Last-Modified: Tue, 08 Sep 2015 08:46:10 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Etag: "-xxx-"
Date: Sat, 12 Sep 2015 11:50:30 GMT
Content-Type: application/javascript
Content-Length: 435035
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Here is a request for an external asset reporting HTTP/2.0 200:
Request-URL: https://fonts.googleapis.com/css?family=Ubuntu
Request-Methode: GET
Status-Code: HTTP/2.0 200 OK
Request-Header 13:50:31.000
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Referer: https://myserver/index.php
Pragma: no-cache
Host: fonts.googleapis.com
DNT: 1
Connection: keep-alive
Cache-Control: no-cache
Accept-Language: de-DE,en-US;q=0.8,de;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept: text/css,*/*;q=0.1
Response-Header Δ87ms
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Firefox-Spdy: h2
X-Content-Type-Options: nosniff
Timing-Allow-Origin: *
Server: GSE
Expires: Sat, 12 Sep 2015 11:50:31 GMT
Date: Sat, 12 Sep 2015 11:50:31 GMT
Content-Type: text/css
Content-Length: 308
Content-Encoding: gzip
Cache-Control: private, max-age=86400
alternate-protocol: 443:quic,p=1
Alt-Svc: quic=":443"; p="1"; ma=604800
access-control-allow-origin: *
I read this anouncement How NGINX Plans to Support HTTP/2, which helped me understand why I may still see requests being made to applications with HTTP/1.1. However I didn't compile Nginx with the patch myself and I wouldn't know what to look for in the source, but my guess is that Nginx pre-HTTP/2 just reports HTTP/1.1 status codes even if it does use SPDY while other software (like GSE) may behave differently.
