Do current XHR implementations take advantage of HTTP/2?

Question

This may just highlight some misconception of mine, but I was curious:

If you had an HTTP/2 server running and wanted to make XHR requests in the browser to the server, would XHR automatically take advantage of the performance optimisations in headers and such that it provides?

Or would it ignore that functionality and operate as an HTTP request? If so, are there any things we can do to use the new optimisations in our requests?

Vonnie

ajax operates on an http1.1 interface, at least for now. some of the perf optimizations would be transparent (header compression), some won't apply (multiple resources). – Hirohito

@Hirohito Not sure if I get you correctly. Which browser are you talking about? – Diabolism

@dsign: all of them; xmlHttpRequest level 2 came out before http2, so there are (afaik) no new methods or capabilities to the ajax interface (based on http1.1), even if the underpinning layers use http2. to the point of the question: the browser takes advantage of http2, but JS code does not let the coder take any additional advantages over http1... – Hirohito

@Hirohito "would XHR automatically" ... sorry, I didn't realize that Nick was asking about new toys in the API. Anyway, it is an interesting exercise to imagine what those extensions could be. AFICS the only one would be to adopt pushed streams, and that is already possible, in a way. – Diabolism

Answer 1

You don't need to do anything. If the server supports HTTP/2, XHR will use it. Header compression and such will kick in automatically.

Test it:

• Open an HTTP/2 website in Chrome. You can use ours, to also checkout some cool stuff regarding HTTP/2 PUSH, AngularJS and RequireJS.
• Open Devtools panel (F12), then the network panel, and then click XHR. Right click the headers row, and ensure you have the "Protocol" column enabled.
• You should see "h2" in said column ( in our case, AngularJS is loading a template include through XHR).
• While you are at that, notice that the server pushed the XHR request. Tell-tale signs of pushed responses are "provisional headers" instead of request headers, and abnormally small "download" and "waiting" times. We even add an extra-header to the response (x-shimmmercat-note:pushed-stream) . The browser adopted this request, so XHR requests not only will use HTTP/2 if available, but can in some cases use pushed resources.

Diabolism

neat, but where would a pushed resource come out of an ajax request? – Hirohito

is there anything aside from pre-caching? or i guess what i'm asking about is if it changes the view from ajax (the response, status, headers, etc), or if all that stuff acts the same as it used to. from what i can tell, the ajax api interaction is the same as it used to be, is that your understanding as well? – Hirohito

@Hirohito Yes, I think you have it right. The Ajax request would even have a hard time realizing that the resource was pushed. But let me tell you, HTTP/2 push is way too new (not really, but only slowly starting to take off) even removing XHR from the equation. – Diabolism

XHR.onprogress can be used to recieve the pushed resources. – Darwindarwinian