1

Questions

  • Do I have to look at response headers like X-Firefox-Spdy to 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:


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.

  • @Anatoly As I said "I wouldn't know what to look for in the source" and it doesn't appear to be an obvious literal. Do you know what to look for in the source? If you don't then your comment is offensive or not constructive and should be removed. – LiveWireBT Sep 20 '15 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.