The most use cases for http/2 server push is to pre-emptively push assets files (such as javascript and css files) to browser. I am wondering can http/2 server push be used to send dynamic payload such as JSON documents to client application? From the http2-spec, it doesn't mention anything about this. Can anyone elaborate more on this? Why or why not?
HTTP/2 is not intended as a replacement of websockets in that you make a request (e.g. a web page) and may get several resources back (e.g. The web page, the CSS needed to display the webpage, JavaScript needed to run that webpage... etc.).
HTTP/2 is therefore not truly bidirectional in that it still responds to an initial request.
So if you're intending to send the JSON request in response to the initial request then that's fine - it's just another resource in much the same as CSS and javascript.
However if you're intending to keep the channel open to continually send further JSON payloads to keep your page up to date then that's not what HTTP/2 is intended for. That's what websockets are for.
This question has some further details on HTTP/2 versus websockets: Does HTTP/2 make websockets obsolete?
Yes, you can use HTTP/2 Push to send any type of assets. But keep in mind the following:
As BazzaDP said, HTTP/2 Push is not a push notification mechanism. But HTTP/2 is excellent for doing long polling, and then you have content-encoding compression, encryption, HTTP headers and flow control, so for 90% of the cases you can and probably should skip websockets anyway. Notice that when doing long polling, HTTP/2 Push is not required.Also notice that there is something called Server Sent Events which sort of is the browser-endorsed version of long polling.
HTTP/2 Push is so far transparent to the application. Meaning that you have to do the Push and do a request for the resource from your application.
For now, only cacheable things are made available to the application. That means that you need to set cache headers in the dynamically generated JSON response. Probably you can set a short expiration time, or a long one but under a dynamic URL.
Related
I have a webpage that has JS, CSS, and font assets. The page has to do some heavy processing before determining the HTTP Status code and headers for its response.
I'd like to use HTTP/2 Push to send the assets to the browser without waiting on this heavy processing. The timeline would look something like this:
Client requests index.html
Server sends PUSH_PROMISES for script.js, styles.css, and font.woff2
Server sends HTTP headers and data for the assets above
Server does some heavy processing to determine index.html response...
Server sends HTTP headers and data for index.html
Is this possible? Based on my understanding of Server Push in the HTTP/2 spec, it appears possible. However, it's my first time diving into the HTTP/2 spec, so I could definitely be missing something.
Yes that’s totally allowed and it’s possible in Apache for instance as detailed here: https://icing.github.io/mod_h2/earlier.html
Or an example with Node is given here: https://github.com/bazzadp/http2-in-action/blob/master/Listing%205.3/app.js
Other servers may allow this too, but many servers use preload HTTP headers as signals to push so that needs the response to be sent sent back to show the header.
An extra 103 Early Hint response has been defined which can be sent back early with these headers while your main response is being processed, however support of this is poor not least because some implementations will be confused to get back two responses (a 103 followed by a 200).
What you want to do is possible, but the details of how to do it depend on the technology that you have chosen.
Your application needs to have explicit HTTP/2 APIs to push assets to the client.
For example, if you use Java and Servlet, you need to use Servlet 4.0 which has introduced the PushBuilder APIs to explicitly push assets, and this can be done independently from the main resource response, like you would like to do.
I'm sure other technologies such as NodeJS have similar APIs that you can leverage, but you have to check with the technology you are using.
Its been sometime I heard about server push,
Will HTTP/2 server push only works for web assets ?
or will it work for other JSON data also ?
It can be used for any cacheable resource which will be used by that page.
Note however that there have been reports of confusion on how exactly to enable it for XHR resources as discussed here: HTTP2 Push XMLHttpRequest Cache Miss in Chrome
If you mean however for general JSON rather than XHR JSON that will be used by the page then no, that is not what HTTP/2 push is for. See here for more details: HTTP/2 Push JSON Payload
The most use cases for http/2 server push is to pre-emptively push assets files (such as javascript and css files) to browser. I am wondering can http/2 server push be used to send dynamic payload such as JSON documents to client application? From the http2-spec, it doesn't mention anything about this. Can anyone elaborate more on this? Why or why not?
HTTP/2 is not intended as a replacement of websockets in that you make a request (e.g. a web page) and may get several resources back (e.g. The web page, the CSS needed to display the webpage, JavaScript needed to run that webpage... etc.).
HTTP/2 is therefore not truly bidirectional in that it still responds to an initial request.
So if you're intending to send the JSON request in response to the initial request then that's fine - it's just another resource in much the same as CSS and javascript.
However if you're intending to keep the channel open to continually send further JSON payloads to keep your page up to date then that's not what HTTP/2 is intended for. That's what websockets are for.
This question has some further details on HTTP/2 versus websockets: Does HTTP/2 make websockets obsolete?
Yes, you can use HTTP/2 Push to send any type of assets. But keep in mind the following:
As BazzaDP said, HTTP/2 Push is not a push notification mechanism. But HTTP/2 is excellent for doing long polling, and then you have content-encoding compression, encryption, HTTP headers and flow control, so for 90% of the cases you can and probably should skip websockets anyway. Notice that when doing long polling, HTTP/2 Push is not required.Also notice that there is something called Server Sent Events which sort of is the browser-endorsed version of long polling.
HTTP/2 Push is so far transparent to the application. Meaning that you have to do the Push and do a request for the resource from your application.
For now, only cacheable things are made available to the application. That means that you need to set cache headers in the dynamically generated JSON response. Probably you can set a short expiration time, or a long one but under a dynamic URL.
In chunked downloading, there are extensions on each chunk that can be leveraged when coming to a browser. the last chunk can also contain optional headers defining stuff like content-length if we streamed a big file through, we can provide that information at the very end in the form of a http header.
How does this work in http/2? Are there even extensions or headers in last piece. I see there is Data payload but there is no extensions nor optional headers AFAICT. I only see padding.
Maybe a better question is do browsers even
leverage the optional headers in the last chunk?
leverage extensions in each chunk?
Perhaps programs may care but if it is a progam, I believe in http/2, the server just defines the api better perhaps and uses a push mechanism after response+data has been sent maybe?
How would one send optional headers in this new http/2 world though if I was a server defining an api for clients?
I was trying to use wireshark to capture a download trace but chrome seems to use QUICK and I can't seem to decrypt the SSL with wireshark for this use case when I use firefox and drive.google.com to download a file(it stays encrypted while in the same trace, I actually saw some http2 traffic in TLS for some other service working just fine). Using the "(Pre)-Master-Secret log filename" seems to only work half the time and I am not quite sure why. I end up having to restart everything and re-run my cases.
Also, in the Server hello, h2 was the protocol selected but then no http2 packets appear when I filter to ip.addr=(server hello google ip) and tcp.port=443
thanks,
Dean
In chunked downloading, there are extensions on each chunk that can be leveraged when coming to a browser. the last chunk can also contain optional headers defining stuff like content-length if we streamed a big file through, we can provide that information at the very end in the form of a http header.
In theory (i.e. standard) you have the extensions and the possibility to add non-essential(!) headers at the end. In practice these feature are not used. I'm not aware of any chunk extensions which are defined which means that browsers simply ignore them. And the example trailer defining a content-length makes no sense because with chunked encoding any content-length header should be ignored. There might be some third party libraries which make use of trailers. But since support for trailers would need to be declared up-front by the client (using TE:trailers header) browsers don't use it.
If I understand HTTP/2 correctly chunk extensions are simply gone (nothing lost, they were never used). Trailers are still possible, i.e. you could add headers after all data are sent, see RFC7540: 8.1 HTTP Request/Response Exchange.
I'm serving up tiny little chunks of minimized javascript through Google App Engine, and I think the GZIP-unGZIP process is slowing me down unnecessarily. (To clarify, I'm sending them quickly to many different websites who request them and I've optimized most of the other parts of the process).
For reference the files are so small that the GZIP savings can be less then the "Content-Encoding: gzip" header.
However, from the documentation
If the client sends HTTP headers with the request indicating that the client can accept compressed (gzipped) content, App Engine compresses the response data automatically and attaches the appropriate response headers.
Is there a setting in app.yaml or somewhere that I can disable GZIP-ing? It must be possible since some files are served unzipped.
It's not currently possible to change this behavior from the server side (although, if you control the client, you can remove gzip from its Accept-Encoding header to accomplish the same thing)
There's an open bug about this with Google, and a team member has marked it "Acknowledged", but it doesn't look like there's been any action on it in the last year or so. You should probably add your voice to that ticket and star it for future notifications.