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.
Related
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).
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
I have started to develop a Rails application, and decided to use websockets as a way to push notifications to the client - and am using basic HTTP requests to get and manipulate data on the server.
Now, websockets allows you to send messages from the client to the server, a feature I currently am not sure when to use - I mean I can always do post requests.
This feels somewhat odd to me - so I guess I am doing something wrong - why should I send HTTP requests when there is already a connection between the client and the server? it could just send a message through the websocket, and request the data to be pushed back to it.
I guess the websocket protocol isn't meant to fully replace http - and servers should support both - so I am wondering, what was the intended usage? - when should I send messages from the client through the websocket and when should I use POST for example?
Can anyone provide an example of a simple HTTP server implemented using Netty, that supports persistent HTTP connections.
In other words, it won't close the connection until the client closes it, and can receive additional HTTP requests over the same connection?
This is exactly one of the things their sample http code demonstrates.
My Question is related to the HTTP Streaming Method for realizing HTTP Server Push:
The "HTTP streaming" mechanism keeps a request open indefinitely. It
never terminates the request or closes the connection, even after the
server pushes data to the client. This mechanism significantly
reduces the network latency because the client and the server do not
need to open and close the connection.
The HTTP streaming mechanism is based on the capability of the server
to send several pieces of information on the same response, without
terminating the request or the connection. This result can be
achieved by both HTTP/1.1 and HTTP/1.0 servers.
The HTTP protocol allows for intermediaries
(proxies, transparent proxies, gateways, etc.) to be involved in
the transmission of a response from server to the client. There
is no requirement for an intermediary to immediately forward a
partial response and it is legal for it to buffer the entire
response before sending any data to the client (e.g., caching
transparent proxies). HTTP streaming will not work with such
intermediaries.
Do I avoid the descibed problems whith proxy servers if i use HTTPS?
HTTPS doesn't use HTTP proxies - this would make security void. HTTPS connection can be routed via some HTTP proxy or just HTTP redirector by using HTTP CONNECT command, which establishes transparent tunnel to the destination host. This tunnel is completely opaque to the proxy, and proxy can't get to know, what is transferred (it can attempt to modify the dataflow, but SSL layer will detect modification and send an alert and/or close connection), i.e. what has been encrypted by SSL.
Update: for your task you can try to use one of NULL cipher suites (if the server allows) to reduce the number of operations, such as perform no encryption, anonymous key exchange etc. (this will not affect proxy's impossibility to alter your data).