does it make sense to server-push woff2? - http2

I'm reading quite a bit about http2's server-push. Also did some experimenting (on a beginner's level)...
Well, my question is: Does it make sense to server-push woff2 web-fonts? (since not every browser uses them), and, is there a method to push the correct font (if not already in the cache)?
Zach points out how important it is to have a fast font-delivery-solution, and CSS-Tricks (Chris Coyer) has a great method to get it done cache-aware...
Thank you!
david

Well that's an interesting question alright. The answer is: No you should not do this. But the reason is a little different than you might think...
For reasons that are a bit cryptic, fonts are always requested without credentials (basically cookies). For most browsers (Edge being the exception) this means the browser opens another connection for that request and this is important because HTTP/2 Pushes are linked to the connection. So if you push a resource on one connection, and the browser goes to get a resource from another connection it will not use that pushed resource (you do not push directly into the HTTP Cache as you might think).
This, and lots of other HTTP/2 Push trickiness and edge cases were discussed by Jake Archibald in his excellent HTTP/2 push is tougher than I thought article.
But it does beg the question of how you can decide what format to push even if this wasn't an issue, or if you wanted to send different image formats for example (that would be on the same connection). Other than looking at the User-Agent and guessing based off of that, there is now way for you to know what the browser supports.
There is a new HTTP Client Hints header currently being proposed which aims to allow the browser to indicate the device specifics. This currently is more concerned with image size and density, but could in theory also include the file formats that are supported.

Related

HTTP2 does not yet support etags?

I am currently making a server for dynamic and static files with Node. I'm trying to implement HTTP2. What surprises me is that it seems that the HTTP2 push does not support ETags!
When the client sends the headers to retrieve a file that starts with a push, and that it has accepted, it ignores the "IF-NONE-MATCH" header.
It's a waste, I do not understand the reason for this behavior. Is this the case or am I missing something?
As discussed in the comments the server pushes the resource, so there is no client request, so there is no Etag to send.
So HTTP/2 does support Etags - they just have no relevance for pushed requests.
And yes this does mean cached resources are ignored for Pushed resources - which is one of the big drawbacks of Push and why many people do not recommend using it. When a client sees the PUSH_PROMISE that a server sends before pushing a resource, it can reject it with a RST_STREAM request but by the time that makes it to the server often a good part (if not all) of the resource will have already been pushed.
There are a few ways around this:
You could track what has already been pushed using cookies for example. I've a simple example with Apache config here: https://www.tunetheweb.com/performance/http2/http2-push/. Of course that assumes that cookies and cache are in sync but they may not be (they can be cleared independently).
Some servers track what has already been pushed. Apache for example allows an HTTP/2 push diary to be configured (set to 256 items by default) which tracks items pushed on that connection. If you visit page1.html and it pushes styles.css, and then you visit page2.html and it also attempts to push styles.css Apache will not push it as it knows you already have it. However that only works if you are using the same connection. It you come back later on a new connection, but it's still in the cache then it will be re-pushed.
There was a proposal for Cache digests, which allow the browser to send an encoded list of what is in the cache at the start of any connection, and the server could use that to know whether to push an item or not. However work on that has been stopped recently as there were some privacy concerns about this.
Ultimately HTTP/2 Push has proven to be tricky to make useful and usage of it is incredibly low because of this. In large part due to this, but also because it is complex and there are other implication issues. Even if all those were solved, it's still easy to over push resources when perhaps it's best to let the browser request the resources in the order it knows it needs them. The Chrome team have even talked about turning it off and not supporting it.
Many are recommending using Early Hints with status code 103 instead, as it tells the browser what to request, rather than just pushing it. The browser can then use all it's usual knowledge (what's in the cache, what priority it should be requested with...etc.) rather than overriding all this like Push does.
Cheap plug, but if interested in this then Chapter 5 of my recently published book discusses this all in a lot more detail then can be squeezed into an answer on Stack Overflow.

Connection Status Widget for Web Page

I'm working on an Ajax-heavy web app, and we're getting complaints of flaky behavior in situations where the user has an iffy network connection. As a first step in dealing with the issue, we'd like to add a network status widget to the top right corner of the affected pages.
The simplest version would be to have a script ping the server via Ajax every n seconds and show a green light/red light depending on whether or not it succeeded; that should be pretty easy to implement. However, is there an available widget that does something like this, possibly with a more sophisticated or informative approach? My initial Google searches haven't turned up anything, so I'm checking in here to see if anybody knows of any good existing solutions to this problem.
Some links that might help.
Detect that the Internet connection is offline? This question might prove helpful if you decide on creating your own or it might have the answer outright. There are many helpful answers.
How to Detect if Your Server Is Down When Making jQuery Ajax Calls - Might also prove helpful for a homegrown solution.
Check if Internet Connection Exists with Javascript? - More good suggestions for a simple AJAX solution.
Detecting offline status in HTML 5 - might be helpful.
Based on my findings I think your simple AJAX solution described in the question would work best. I didn't see any established widgets out there. Nevertheless, I would still review some of the suggestions/answers in the links as there were many clever solutions for different situations.

Sending messages between computers

I'd like to start investigating client/server communication. I've started to look at Distributed Objects and a tad at CFNetwork. Let's just say I'm looking for something more my speed (which is slower).
I'd like to be able to send a message from one computer to another, possibly carrying a string or some other type of data. I'm thinking of building a simple student response system where one computer is acting as a server and the clients are connecting and sending data to it.
I'm looking for resources that might help me out as well as suggestions of where to start understanding the concepts involved. I've been teaching myself Objective-C and am a relative newbie to programming, so I know I have holes in my understanding.
"Sockets" is the canonical answer.
If you're interested, here's a great introduction to socket programming (biased toward C, but still very informative):
Beej's Guide to Network Programming
Another way of doing it really simple is by letting the server set up a local http server (inside it self), and then let the clients simply make http requests. By doing that you let the http layer do all the fancy sockets stuff. More simple, and with more overhead, but may be suitable for your case. Also a lot easier to debug, since you can use your browser to test the connection. There are many ways of implementing a HTTP server in cocoa, can't remember which one i've used, but a quick google pointed me at this one for example

How do comments appear instantly on Facebook?

I was just wondering, How do comments appear instantly on Facebook? For example, when I'm on my profile and my friend comments something on my post, I can instantly see it. Is it AJAX? Or Queuing system? If I want to do the same thing, what do I do?
Thanks
I'm not exactly sure how facebook has implemented their system.
but it will either work with websockets, AJAX or a comet server.
If you want to have the same effect there are a lot of different techniques you could use,
but I would recommend looking into node.js and maybe even the now.js plugging, which allows for realtime updates via websockets. It even has support for older browsers, so if the browser does not support websockets, it will do a fall over to either a comet server implementation, AJAX or an iframe.
Basically websockets allow for better control over when data should be sent or received from and to the server since it constantly listening to the socket, so you only send data when required and same for receiving data as well, where with an AJAX approach you had to make a call every X seconds.
It's extremely easy to setup on a linux environment, and there's ample documentation to get you started.
It works with javascript and is build on the Google V8 engine, so if you've ever worked with OOP Javascript, you should be able to pick it up relatively easy.
LINKS:
http://nodejs.org/
http://nowjs.com/
You'll want to look into PHP sockets
Actually, its long polling according to this answer (which also explains how to verify or see if its changed since the answer):
How does Facebook fetch live updates

What's the Best Way to Open a TCP Stream to Server?

Rather a hard to nail down question, but basically I'm wondering what the best way (and not "what's your opinion" but "which will most adequately meet the requirement i shall set forth) is to open a stream connection from a client side webpage to a server such that either can send data to the other without polling? I'm thinking the term for this is HTTP binding vs. HTTP Polling. The context here is a chat application - i'd like a streamed connection so that the browser isn't constantly pushing requests out. The client end here is KnockoutJS and jQuery. I'd like to be able to have the data pushed back and forth be JSON (or at least manipulatable by jQuery and Knockout's toJSON). The server end - not quite sure what it is going to be, but i'll probably be running on a linux server, so anything compatible with that works fine.
If there's any more details i can provide, just let me know - i'm sure i left some obvious detail out. Also, i'm aware there's probably a duplicate question on this, so if your answer is as good as closing for a dupe and putting in a link, that's great.
Thanks!
I think what you're looking for is referred to as Comet. The basic idea is to keep HTTP requests open for longer periods of time so that the server can send data to the client as it comes in, rather than the client having to continually poll the server for new data. There are multiple ways to implement it. This Wikipedia article is a good start for more info.
This MIX 2011 video discusses the long polling technique (although the suggestion in the video is that web sockets will be a better solution with future browsers).

Resources