In the EventSource specification:
http://www.w3.org/TR/eventsource
There is a section titled: Connectionless push and other features
Does anyone know if this is actively developed / supported on applicable browsers? If so who is leveraging this feature of the spec?
I reached out to Ian Hickson (author of the eventsource rfc). He's given me permission to repost his answer here:
"I haven't heard of any implementations. That section was added by
request from some network-associated handset vendors a few years ago.
Since then, the landscape has changed quite a bit and networks and
handset vendors don't work as closely together."
Related
I plan to code a mighty web server. But I am unsure: should I do it in HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is going to be adopted by the majority then I will only do it in HTTP/2 without the backward compatibility aspect).
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Is HTTP/2 really worth it?
Finally, how is the expected HTTP/2 adoption by web browsers?
I would say this question is too broad for stack overflow, but will attempt and answer anyway:
I plan to code a mighty web server. But I am unsure: should I do it in
HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know
HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is
going to be adopted by the majority then I will only do it in HTTP/2
without the backward compatibility aspect).
No offence, and will give you the benefit of the doubt here that you are not trolling, but writing a web server is a major undertaking and you'd need to have detailed knowledge of the HTTP protocol amongst other things and it appears you don't have that to be honest. So you'll need to do a few years reading on the subject first.
HTTP/2 is not backwards compatible to HTTP/1.1. You basically start in HTTP/1.1 and upgrade to HTTP/2 if you support it (at a simplistic level). So you need to support both. And will do for some time. Even though browser support is good (see below) there will be numerous devices that won't speak HTTP/2 for some time. Some devices (primarily bots admittedly) still only speak HTTP/1.0.
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Way too broad for Stackoverflows format.
Is HTTP/2 really worth it?
Yes.
Finally, how is the expected HTTP/2 adoption by web browsers?
HTTP/2 adoption can be seen here: http://caniuse.com/#search=http2
How is the future looking like for HTTP/2? and Finally, how is the expected HTTP/2 adoption by web browsers?
The HTTP/2 standard has passed acceptance and is being implemented by all major server vendors. In fact, server support has advanced, all major server vendors support HTTP/2 in their current releases. You can track all known implementations of HTTP/2 here.
Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
There will not be an HTTP 2.x. The standards body has already made this clear (although I can't find a link that proves it). the next version will be HTTP/3.
Is HTTP/2 really worth it?
Yes. The benefits of HTTP/2 are too long to list here. This article discusses them in depth.
When developing a web server you will need to take account of both HTTP1.x and HTTP/2. At the moment we are transitioning to HTTP/2 but you should provide backward compatibility to HTTP/1.x.
How can we know how many browsers support HTTP 2.0?
How can we know how many browsers support HTTP 2.0?
A simple Wikipedia search will tell you. They cover at least 60% of the market and probably more once you pick apart the less than 10% browsers. That's pretty good for something that's only been a standard for a month.
This is a standard people have been waiting for for a long time. It's based on an existing protocol, SPDY, that's had some real world vetting. It gives some immediate performance boosts, and performance in browsers is king. Rapid adoption by browsers and servers is likely. Everyone wants this. Nobody wants to allow their competitors such a significant performance edge.
Since http 2.0 is rolling out, does tricks like asset bundle still be necessary?
HTTP/2 is designed to solve many of the existing performance problems of HTTP/1.1. There should be less need for tricks to bundle multiple assets together into one HTTP request.
With HTTP/2 multiple requests can be performed in a single connection. An HTTP/2 server can also push extra content to the client before the client requests, allowing it to pre-load page assets in a single request and even before the HTML is downloaded and parsed.
This article has more details.
When can we move on to the future of technologies and stop those dirty optimizations designed mainly for HTTP 1?
Three things have to happen.
Chrome has to turn on their support by default.
This will happen quickly. Then give a little time for the upgrade to trickle out to your users.
You have to use HTTPS everywhere.
Most browsers right now only support HTTP/2 over TLS. I think everyone was expecting HTTP/2 to only work encrypted to force everyone to secure their web sites. Sort of a carrot/stick, "you want better performance? Turn on basic security." I think the browser makers are going to stick with the "encrypted only" plan anyway. It's in their best interest to promote a secure web.
You have to decide what percentage of your users get degraded performance.
Unlike something like CSS support, HTTP/2 support does not affect your content. Its benefits are mostly performance. You don't need HTTP/1.1 hacks. Your site will still look and act the same for HTTP/1.1 if you get rid of them. It's up to you when you want to stop putting in the extra work to maintain.
Like any other hack, hopefully your web framework is doing it for you. If you're manually stitching together icons into a single image, you're doing it wrong. There are all sorts of frameworks which should make this all transparent to you.
It doesn't have to be an all-or-nothing thing either. As the percentage of HTTP/1.1 connections to your site drops, you can do a cost/benefit analysis and start removing the HTTP/1.1 optimizations which are the most hassle and the least benefit. The ones that are basically free, leave them in.
Like any other web protocol, the question is how fast will people upgrade? These days, most browsers update automatically. Mobile users, and desktop Firefox and Chrome users, will upgrade quickly. That's 60-80% of the market.
As always, IE is the problem. While the newest version of IE already supports HTTP/2, it's only available in Windows 10 which isn't even out yet. All those existing Windows users will likely never upgrade. It's not in Microsoft's best interest to backport support into old versions of Windows or IE. In fact, they just announced they're replacing IE. So that's probably 20% of the web population permanently left behind. The statistics for your site will vary.
Large institutional installations like governments, universities and corporations will also be slow to upgrade. Regardless of what browser they have standardized on, they often disable automatic updates in order to more tightly control their environment. If this is a large chunk of your users, you may not be willing to drop the HTTP/1.1 hacks for years.
It will be up to you to monitor how people are connecting to your web site, and how much effort you want to put into optimizing it for an increasingly shrinking portion of your users. The answer is "it depends on who your users are" and "whenever you decide you're ready".
We're all familiar with popular protocols like IMAP and POP, used for email messaging.
I have a plan for a new protocol, but I'm not sure to go about implementing it.
Is the protocol a collection of C source code, for example, that accepts and sends data through ports? Or is a protocol just a thorough description of how data should be sent, which clients then implement?
I'm lost where to start here, and I'm not very familiar with how the protocol system works.
Edit:
Also, if I write a protocol and it isn't made official by the standards group, can people/clients still implement it?
The official way is to write an RFC - a Request for Comments. People will respond to that (that's why it's an RFC) and probably try to implement your protocol.
As soon as two independent implementations exist that completely support the protocol, it's a new standard.
Of course, people aren't going to implement a new protocol for someone just for fun. So you should first find a group who is interested in listening to you. Maybe there already is a protocol which does what you want (or can easily be extended).
But you probably don't want to invent a new standard. Standards are a lot of work and - for some - overrated.
So you should describe how it works and create a library that can read and write the protocol, so developers can use it even though it's not an official standard.
As you are interested in the Replace Email section of the Paul Graham article you linked, then IMHO you will need to both develop a protocol definition, and also provide an example implementation. The protocol definition does not need to be published as an internet protocol standard in order to be useful.
You will need an implementation to so that you can test, refine and improve the ideas. It is extremely unlikely the protocol will be right at the first attempt, and you'll need something to support the initial users.
You don't need a protocol definition to implement an improved email, but you will need one if you expect others to work with you and adopt it, though it very much depends on your 'business model'. I strongly recommend you have a protocol definition from the start, even if only to keep yourself sane when you try to produce the second implementation.
I recommend having a look at some examples of sneaky approaches to protocols and implementation. My favourite is described in the Viewpoints Research 2008 Progress report on a super-compact approach to TCP/IP.
They did not follow the traditional approach to developing the implementation of a protocol (the protocol stack). Instead they wrote code which parsed the human-readable TCP/IP protocol specification, and generated the code of a TCP/IP stack from that protocol document. The usual TCP/IP stack is about 40,000 lines of code, or more. Their program, which read the protocol specification, and generated the code for a TCP/IP stack 'automatically' was only 160 lines of code. They use extremly powerful programming tools.
If you had an approach like that, you could keep the protocol implementation synchronised with the specification, and potentially make it straightforward for others to adopt your protocol.
HTH
You are confusing a protocol standard with the implementation.
These 2 are unrelated.
A protocol is described in a high level but has enough information for someone to undestand how it should be implemented.
The idea is that someone reading the document can understand how/what to implement in any language of preference
To give an example: SIP protocol in the RFC describes the various flows and also has the various messages and how they are supposed to b processed i.e. the semantics well defined.
You can implement a SIP UA or Server in C++ or Java. This is irrelevant to the SIP protocol
For this you don't need to provide any source code (you could though if you think it helps clarify some obscurity of the description).
The most important part is that your protocol is actually reviewed by stakeholders i.e. people that expect it to solve their problems.
This part is the most important not only because it could solve problems in your protocol but because they can actually verify that the concept is solid i.e. can be technically implemented
The only case that one could specify something concrete or imply something is if for example the protocol described something demanding some specific constraints e.g. hard-real time constraint which could serve as "hint" on which implementation/languages to avoid
Also, if I write a protocol and it isn't made official by the
standards group, can people/clients still implement it?
Strange question.What do you mean?How will someone know your protocol exists?
If it is official he can get it from the standards group to implement it.
Otherwise it is obvious that you have some sort of "proprietary" protocol (which is not uncommon e.g. a company can have an internal protocol for its own software) and people have to get the spec from you.
I have been studying the Upgrade header field in HTTP 1.1 (RFC 2817) and happened to read the wikipedia entry for HTTP. That article has the following statement:
"Browser support for the Upgrade header is, however, nearly non-existent, so HTTPS is still the dominant method of establishing a secure HTTP connection."
I was hoping to implement my web service so that it relied on the Upgrade header field in order to avoid having to listen on two sockets (one for HTTP and the other for HTTPS). This statement, which I have not been able to verify any other place, makes me somewhat nervous about doing so. Is the above statement in wikipedia anywhere near correct or is it a gross generalisation?
I was researching this for that Wikipedia page actually and came across this question. I've looked around and here's the browser support situation as near as I can tell:
Chromium supports the Upgrade header as indicated by, for instance, this bug.
Firefox does not support "Upgrade: TLS" despite an open bug from 2005, last comment from 2010. My guess is they won't be adding it anytime soon.
Internet Explorer 10+ probably does, given this article that describes using Upgrade to connect to a websocket server. This commit message also implies IE 10 supports "Upgrade: websocket".
Safari 6+ supports Upgrade (see here).
For all of the supported browsers, I only found examples of "Upgrade: websocket" usage, none saying that upgrades to TLS would work. So the overall answer is that it's risky to rely on this in a production application.
Server support seems better; Apache has had "Upgrade: TLS" support since 2.1.
I would rather like to have it all in http, but the current situation leans more to Server Name Indication, as its widely supported. Its also hard to indicate that you want the client to upgrade using the url. So, if the goal is virtual hosting, one way to do this is TLS "server name indication". See RFC 3546 http://www.ietf.org/rfc/rfc3546.txt or http://en.wikipedia.org/wiki/Server_Name_Indication
What do you think of Quagga compared to XORP as a dynamic software routing engine? What are the technical merits of each engine comparatively? Additionally, what do most people think of them from a programming view. Who has manipulated networks using these enginers? I was wondering from an OSPF, routing, BGP protocol user's perpspective.
The following does not answer your question completely, but the Vyatta open source routers and the OpenSolaris customer gateway software for Amazon VPC both use quagga to implement BGP support.
From the wikipedia entry for XORP,
"The software suite was selected
commercially as the routing platform
for the Vyatta line of products in its
early releases, but later has been
replaced with quagga.
What do you think of Quagga compared to XORP as a dynamic software routing engine?
It is one of many options, but not particularly of very much use to you based upon your questions/information that you posted here. Have you tried looking into some of the alternatives such as (nothing comes to mind)?
What are the technical merits of each engine comparatively?
Small, fast, oddly placed, optimized, super-heroic and more filler for a resume.
Additionally, what do most people think of them from a programming view.
I can't speak for most people, but I for myself do not give it much credit or merit, or well... you know what I mean.
Who has manipulated networks using these enginers?
I could not find specific references, but I do remember reading that both Disney and the 'famous' YUV corporation of South Africa both played with this notion before. I believe Disney abandoned it with the fall of Michael Eisner.
I was wondering from an OSPF, routing, BGP protocol user's perpspective.
I am a BGP protocol user's prospective. Hopefully we hear from OSPF and routing user's perspectives shortly.
Good question.