In this way, the client can connect the server without ALPN and use http/2 default.
Is that possible？
Yes it is possible, but the conditions are strict.
Browsers, as of now, do not implement clear-text communication for HTTP/2, so if you use a browser the answer to your question is no: you have to deploy your server with ALPN support if you want browsers to be able to connect.
On the other hand, other clients such as Java clients may be able to connect to a server using clear-text HTTP/2, so for those type of clients the answer to your question is yes: you can deploy a HTTP/2 server without ALPN support.
The Jetty Project [disclaimer, I am a committer] implements a web server and servlet container that support both scenarios: you can enable ALPN for TLS (SSL) HTTP/2 communication so that browsers will be able to connect, and you can also enable clear-text HTTP/2 communication as explained here. See also the Jetty HTTP/2 documentation.
Related
Error:
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
I recently purchased a EV SSL certificate from Comodo, installed it on my VPS (cPanel/WHM) and everything worked great. I then upgraded to http2 and am now receiving the error when switching between each website on the certificate. The 3 websites share the same IP address. From what I can tell, this may be the issue. I do not want to reissue a SSL cert for each domain as I paid for the EV multi domain cert. Is the answer to purchase 2 additional IPs and make sure each domain has its own IP? Or is there a way I can edit the virtual hosts so that I can maintain the same setup I have now?
I should mention, this is only happening on Safari, not chrome.
SSL Labs Report
https://www.ssllabs.com/ssltest/analyze.html?d=www.deschutesdesigngroup.com&s=142.4.0.142&hideResults=on
EasyApache HTTP vhost configuration
https://pastebin.com/dNeFRGWJ
EasyApache HTTPS vhost configuration
https://pastebin.com/vgWAD5mg
You have enabled HTTP/2 on only two of the three sites.
HTTP/2 will try to reuse the connection for multiple domains if both the IP address matches and the certificate covers all the necessary domains. This is the case here and so HTTP/2 is reused.
However if you run SSLLabs on all three domains you see a slight difference in the protocol used for Chrome (for example):
Chrome 70 / Win 10 RSA 2048 (SHA256) TLS 1.2 > h2
Chrome 70 / Win 10 RSA 2048 (SHA256) TLS 1.2 > http/1.1
Chrome 70 / Win 10 RSA 2048 (SHA256) TLS 1.2 > h2
And similarly further down in the ALPN setting:
ALPN Yes h2 http/1.1
ALPN Yes http/1.1
ALPN Yes h2 http/1.1
So going to the middle domain first will work as it will connect via HTTP/1.1 and so not reuse the connection. However going to the middle domain after initiating a request to either the first or last domain will attempt to reuse the HTTP/2 connection and fail as the middle domain doesn't support HTTP/2.
Web servers should return a 421 Misdirected Request status code for any requests when the browser attempts to reuse the connection when it shouldn't, to say "Yeah you really shouldn't be attempting to reuse the connection here! Can you try again on another connection please?". The same thing happens if there are different SSL/TLS setup (e.g. the cipher suite used for the connection is not accepted on the other domain).
Chrome and Firefox correctly handle the 421 response and transparently resend the requests over a new connection, which in this case then uses HTTP/1.1 (check out developer tools in the browser and you'll see this is true). Other browsers, including Safari used by iOS, have not implemented support of the relatively new 421 status code yet and so fail with an error like below:
Misdirected Request
The client needs a new connection for this request as the requested
host name does not match the Server Name Indication (SNI) in use for
this connection.
I presume there is no reason not to enable HTTP/2 on all domains and this was a misconfiguration error? If so enable HTTP/2 in all domains and your issue should be sorted.
If you do not want HTTP/2 on all domains, then you ensure the browser doesn't think it can reuse the connection. That means either using a separate IP address for that domain, or getting the certificate reissued for only two domains, and a separate certificate for the other than shouldn't share connections.
I am trying to make myself familiar with websockets. It is possible to create tunnels with websockets
https://github.com/erebe/wstunnel
You can even tunnel VPN protocols like wireguard through it.
Would it be possible to use Chrome and Nginx in a similar way?
A websocket connection is established between both. A client uses the websocket of Chrome to funnel its traffic through the tunnel. On the nginx end data leaves the tunnel and gets forwarded to the internet.
Like: Client --> Chrome Websocket --> Websocket Tunnel --> Server --> Internet
Will this work in principle? Can clients (like other programs running on the machine or different devices on the network) use the websockets opened by Chrome? Is there a limitation on what the client can be? Are websockets standardized in a way that they are compatible (like a wstunnel client but nginx endpoint)?
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.
I'm running a websocket server and asking myself, if it's planed, that clients authentication will be done with handshake in future... draft xxxx maybe :)
Do you have information? I have heard that with draft07 a session id can be sent to server, so maybe that can help to auth the client...
What I'm doing atm is to wait a maximum of 10 seconds, till the clients sends me a message with login header, username and password. But i think this is not "THE" solution. How do you guys out there doing it?
The WebSockets protocol permits standard HTTP authentication headers to be exchanged during the handshake. If you have a WebSockets server that plugs into an existing web server as a module then existing authentication in the web server should already work. Otherwise if you have a standalone WebSockets server then you may need to add the authentication support.
Update
As #Jon points out, unlike normal HTTP/XHR requests, the browser API does not allow you to set arbitrary "X-*" headers for WebSocket connections. The only header value that you can set is the protocol. This is unfortunate. One common solution is to use a ticket based system that relies on existing HTTP mechanism for authorization/authentication and then this ticket is passed along with the websocket connection and validated that way: https://devcenter.heroku.com/articles/websocket-security
When using WebSockets, will I need to write server code? In other words, will the JavaScript in my client application need to connect to a specialized server, or will my existing Apache server work to support this?
The server has to support web sockets. After a first handshake in HTTP, the server and the client open a socket connection. The server must be able to understand and accept this handshake.
In my last project we run quite successfully web socket connections using the last Jetty version.
27/02/2014:
Now I'm also implementing websockets under .net with XSockets.net and works like a charm, you don't even need a web server (self hosting). The WebSocket implementation of ASP.NET works also quite good.
Yes,you need to write server code.
I recommend another web socket server based on php: ratchet.
And this link is benchmarking webSocket servers between ratchet and sockJS.
Complete list of client & server side codes and browsers support please check this link
Of course you need a WebSocket server. But there are many free websocket server in different language, like jWebSocket in Java and SuperWebSocket in .NET, you can use them directly.
There are some plugins currently being developed on google code for Apache...
By definition websockets like normal sockets are client-server so yes, you need a server. However there is an alternative to waiting for Apache plugins.
I am using a hosted server http://www.achex.ca. Its free and you have tutorials in javascript on how to use the server. A good start for websockets development.
The server is basically a message router and you can connect to it and use it as a meeting point for all your websocket clients.
Short Answer: Yes, You need a specialized server, Apache does not come with websockets.OR The alternative, check out www.achex.ca.
In such a situation the role of server comes when :
In HTML 5,WebSocket like a fone(2-way comm.) not walky-talky.
http protocol upgraded to websocket protocol.(wss:// from ws://)
SERVER should be able to open duplex channel and hence AGREE with duplex communication.
Please go through this link : http://www.html5rocks.com/en/tutorials/websockets/basics/
If using php please look at RATCHET.
Thanks.
The Perl Mojolicious server supports web sockets, and implementations can be only a few lines long.
Node.js has several WebSocket libraries but details of the latest, greatest, most supportive of the latest spec vary, so choose carefully.
Apache Active MQ is also worth a look, along with the stomp protocol it implements.