I am trying to use the same port on the same host.
Websocket URL
ws://aaa.bbb.cc.ddd:eeee/ws
HTTP URL
http://aaa.bbb.cc.ddd:eeee/docs
But when I open the "http://aaa.bbb.cc.ddd:eeee/docs" page, I get this error message.
Failed to open a WebSocket connection: invalid Connection header: keep-alive.
You cannot access a WebSocket server directly with a browser. You need a WebSocket client.
Http does not work. But, websocket is connected normally.
How can I solve this problem?
The WebSocket protocol is not the HTTP protocol.
Although the WebSocket protocol does initiate a new connection using an HTTP request, it quickly upgrades the connection to full WebSocket (which requires a Connection: upgrade header in the initial request, not Connection: keep-alive).
You can't use a vanilla web browser to directly communicate with a WebSocket URL, as such a browser doesn't know how to finish the upgrade, let alone process any WebSocket packets. So, you must use a valid WebSocket client (such as the WebSocket API that modern browsers expose to client-side scripting).
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
It is possible having a wss protocol over http ? i've read on a forum that ws work with http, but wss works only with https ?
Is that true ?
Cause i'm trying to test it on my wamp on localhost, but not working
ws tells a WebSocket client library to use http to connect to a WebSocket server. Likewise, wss tells a WebSocket client library to use https to connect to a WebSocket server. Just that. "ws protocol" and "wss protocol" are strange words. "WebSocket protocol" is the right word. WebSocket protocol can be used over both plain HTTP connections (http) and secure HTTP connections (https).
Note that communication between a WebSocket client and a WebSocket server starts as a normal HTTP protocol. To start WebSocket communication, a WebSocket client sends a request like below to a WebSocket server (This is an excerpt from RFC 6455, 1.2. Protocol Overview).
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
As you can see, this is a normal HTTP GET request. A WebSocket server can wait for this kind of requests on an unsecured port (http, 80 is the default) or on a secured port (https, 443 is the default). It's up to WebSocket servers.
If a WebSocket server you are using is waiting for requests on an unsecured port, pass ws to a WebSocket client library you are using. Otherwise, if the WebSocket server is waiting for requests on a secured port, pass wss to the WebSocket client library.
Some implementations of WebSocket client libraries accept not only ws and wss but also http and https just for developers' convenience.
"WSS on http" is a strange word. On the other hand, "WebSocket protocol on http" and "WebSocket protocol on https" make sense.
I'm not clear why the handshake for WebSocket is HTTP. Wiki says "The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port." What is the benefit of this? Once you start communicating over WebSocket you are using port 80 also...so why can't the initial handshake be in WebSocket format?
Also, how do you have both WebSocket and HTTP servers listening on port 80? Or is it typically the same application functioning as HTTP and WebSocket servers?
Thanks y'all :)
WebSockets are designed to work almost flawlessly with existing web infrastructures. That is the reason why WS connections starts as HTTP and then switches to a persistent binary connection.
This way the deployment is simplified. You don't need to modify your router's port forwarding and server listen ports... Also, because it starts as HTTP it can be load balanced in the same way that a normal HTTP request, firewalls are more lean to let the connection through, etc.. etc... Last but not the least, the HTTP handshake also carry cookies, which it is great to integrate with the rest of the app in the same way that AJAX does.
Both, traditional HTTP request-response and WS, can operate in the same port. Basiclally the WS client sends a HTTP request asking for "Upgrade:websocket", then if the server accepts the WS connections, replies with a HTTP response indicating "101 Switching Protocols", from that point the connection remains open and both ends consider it as a binary connection.
When an http connection is upgraded to a websocket connection can my javascript code still use http ajax GET requests for example? That is, I can do both normal http requests and websocket messages or does "upgraded to websocket" mean the http capabilities are gone?
If your server supports both normal web requests and WebSocket upgrades (some servers are either one or the other), then you can continue to make AJAX requests even while you have a WebSocket connection. AJAX (XMLHttpRequest) requests are just regular HTTP/HTTPS requests that are initiated by Javascript rather than by the browser when the page loads. Having an active WebSocket connection will not interfere with other HTTP/HTTPS (or AJAX) connections. Unless of course the server has a bug.