I have a doubt about using module mod_spdy in my webite:
If I install the module mod_spdy in my Apache Server, What will it happen with the http requests come from desktop and mobile browser which not support the SPDY protocol? (see the browser which not support the SPDY protocol in http://caniuse.com/spdy )
I don’t know if in this case Apache will serve the information using the http protocol or the web browser will have problem to render the information. In the last case, is there any solution to solve the problem with the browser that not support SPDY? For instance, use a web server responding with a different protocol (http or SPDY) depending on which user agent is requesting: browsers support SPDY or browsers only support HTTP.
Thanks in advance,
First of all Apache mod_SPDY supports encrypted connection(HTTPS) only, therefore you have to create a VirtualHost for the 443 port and add your SSL certificate. Mod_SPDY will automatically fallback to HTTPS 1.1 if the browser does not support SPDY. A good use for it is to enable server PUSH. Have fun with SPDY!
Related
For example I have a node server which uses the built-in module "http" (which is http1.1 version I assume). So will it be able to serve any XHR request from browser with http2 protocol?
Yes. Browsers negotiate HTTP/2 as part of the HTTPS setup (since browsers only support HTTP/2 over HTTPS). If HTTP/2 is not supported by both sides it will just use HTTP/1.1
Thanks one of the great things about HTTP/2 and why it’s made such headway - the ability to (almost!) seamlessly roll it out to the web without breaking existing sites/servers/browsers.
I have a nodejs based web app that uses http2 library of nodejs. I start my app
HTTP/2 server is listening on port 3000. PID: 238718.
and want to check app's homepage: http://localhost:3000/
I have an error in Chrome browser: ERR_INVALID_HTTP_RESPONSE
I know that Chrome uses HTTP/2 over TLS (HTTPS).
Does any possibility exist to use HTTP/2 w/o HTTPS in a browsers?
Does HTTP/2 require encryption?
No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.
However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection, and currently no browser supports HTTP/2 unencrypted.
Source: https://http2.github.io/faq/#does-http2-require-encryption
Note that you can just use a self signed certificate for local development
I'm trying to understand what is the difference between HTTPS and http/2?
If I'm going to build a Node.js/express app, what should I use?
Can I use HTTPS with http/2?
Maybe if I use HTTPS, I don't need http/2 because it's the same, or HTTPS use http/2 under the hood?
I'm confused.
Someone is linked to me "difference between HTTP 1.1 and HTTP 2.0 [closed]", but I understand the difference between HTTP and HTTP2. I'm asking about HTTPS and HTTP/2
HTTP - A protocol used by clients (e.g. web browsers) to request resources from servers (e.g. web servers).
HTTPS - A way of encrypting HTTP. It basically wraps HTTP messages up in an encrypted format using SSL/TLS. The web is moving towards HTTPS more and more and web browsers are starting to put more and more warnings when a website is served over unencrypted HTTP. Unless you have a very good reason not to, use HTTPS on any websites you create now.
Digging into HTTP more we have:
HTTP/1.1 - this was the prevalent format of HTTP until recently. It is a text-based protocol and has some inefficiencies in it - especially when requesting lots of resources like a typical web page. HTTP/1.1 messages can be unencrypted (where web site addresses start http://) or encrypted with HTTPS (where web site address start with https://). The client uses the start of the URL to decide which protocol to use, usually defaulting to http:// if not provided.
HTTP/2 - a new version of HTTP released in 2015 which addresses some of the performance issues by moving away from a text based protocol to a binary protocol where each byte is clearly defined. This is easier to parse for clients and servers, leaves less room for errors and also allows multiplexing. HTTP/2, like HTTP/1.1, is available over unencrypted (http://) and encrypted (https://) channels but web browsers only support it over HTTPS, where it is decided whether to use HTTP/1.1 or HTTP/2 as part of the HTTPS negotiation at the start of the connection.
HTTP/2 is used by about a third of all websites at the time of writing (up to 50% of websites as of Jan 2020, and 67% of website requests). However not all clients support HTTP/2 so you should support HTTP/1.1 over HTTPS and HTTP/2 over HTTPS where possible (I believe node automatically does this for you when using the http module). I do not believe HTTP/1.1 will be retired any time soon. You should also consider supporting HTTP/1.1 over unencrypted HTTP and then redirect to HTTPS version (which will then use HTTP/1.1 or HTTP/2 as appropriate). A web server like Apache or Nginx in front of Node makes this easy.
HTTP/3 - the next version of HTTP, currently under development. It is expected to be finalised in 2020 though it will likely be late 2020 or even 2021 before you see this widely available in web servers and languages like node. It will be built on top of a UDP-based transport called QUIC (rather than the TCP-based protocol that HTTP/1.1 and HTTP/2 are based on top of). It will include part of HTTPS in the protocol so HTTP/3 will only be available over HTTPS.
In short you should use HTTP/1.1 over HTTPS, should consider HTTP/2 as well if easy to implement (not always possible as not quite ubiquitous yet - but getting there) and in future you might be using HTTP/3.
I suggest you get a firm understanding of all of these technologies (except maybe HTTP/3 just yet) if you want to do web development. It will stand you in good stead.
My gut feeling is that a SPDY-capable browser will treat it as though it were a SPDY response. However, the most I can find is a reassurance that an H2 response will degrade gracefully to HTTP1.1. I'm considering serving assets in an H2 oriented manner (multiple requests, no domain sharding, etc.), but I do need to support some non-H2 browsers (e.g. Android 4.1's browser). Will I be OK if all the clients are at least SPDY compliant?
Bonus question: are there any complications involved with mixing protocols? We're on a web framework that doesn't support H2, but I'm considering serving most of our assets from a CDN. Assume TLS.
Browsers that are SPDY or HTTP/2 enabled use a TLS extension (either the older NPN or the new ALPN) to negotiate the protocol they speak over TLS.
The client sends the list of protocols that it is capable to speak in order of preference (e.g. h2,spdy/3.1,http/1.1), and the server picks one protocol among those in that list that it also supports (and that match security required constraints).
For example, if you have an older browser that does not support h2, it will send spdy/3.1,http/1.1, and the server will never pick h2 (even if it supports it).
If the server does not support SPDY, the only option left is http/1.1, and this is what constitutes the "graceful degradation" to HTTP/1.1.
There is never the possibility that if the client requested to speak SPDY (and not HTTP/2), the server replies with HTTP/2, unless gross implementation errors on the server.
SPDY is being phased out in favor of HTTP/2. For example, recent Chrome versions don't support SPDY anymore.
There are no complications when you you make requests to different domains, and the servers speak different protocols: this is handled transparently by the browsers.
If your server can speak SPDY and HTTP/1.1, and the CDN can speak HTTP/2 and HTTP/1.1, then you have to use a browser that supports all 3 protocols to leverage the SPDY and HTTP/2 benefits.
The browser can negotiate SPDY with your server, and negotiate HTTP/2 with the CDN, and the page composed of resources from both origins.
However, browsers will soon drop (or have already dropped) SPDY, so with recent browsers you may end up speaking HTTP/1.1 with your server and HTTP/2 with the CDN, thereby losing the SPDY|HTTP/2 benefits for resources on your server.
I'm trying to implement SPDY (with Node.js) for use on a high latency connection.
Now SPDY uses TLS encryption and this would increase the packet length - something I'm trying to avoid.
Is there such thing as a SPDY implementation without the TLS encryption?
Many thanks in advance,
SPDY's framing layer does not need to run over TLS, but for deployment reasons, it almost always does. It's hard to reliably deploy without running encrypted over port 443, because of intermediaries. Note the SPDY whitepaper says: "To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."
That said, the C++ Flip server in the Chromium repository does support running without SSL, and the Chromium browser can be configured to support this.
PS: There's also an existing node.js implementation, see http://www.chromium.org/spdy.
If you want to test your SPDY server locally and without TLS, you can force chrome to use SPDY even without the NPN upgrade. To do so, pass --use-spdy=no-ssl to Chrome when you load it up.
You can confirm that the flag is registered by opening chrome://net-internals/#spdy and checking in there.
If you are implementing a SPDY server using node-spdy, then you can use the plain: true, ssl: false options to achieve what you want.
Its possible to make requests to plain: true spdy-server using spdycat
cli utility, specifying protocol version explicitly (-3 or -2 and
--no-tls). To use it from browser, you will need to start chrome with --use-spdy=no-ssl flag.
But please keep in mind, that SPDY is supposed to on TLS(SSL) server
or behind TLS(SSL) terminator, and otherwise not-suitable for serving
web-content.
https://github.com/indutny/node-spdy/issues/103
I would suggest QUIC protocol which is in development and base on UDP instead of TCP/TLS but still has the benefit like SPDY and Chrome has supported it