When trying to use WCF with NetHttpBinding on IIS 8 Express, the following WebSocketException is thrown on client side when the client attempts to connect:
WebSocket upgrade request failed. Received response status code '200 (OK)', expected: '101 (SwitchingProtocols)'.
Google Search is not helpful.
What could be the cause of this error?
It means the HTTP server does not support WebSockets on that URL. During a WebSocket negotiation, a standard HTTP 1.1 GET request is sent to the server with a special Upgrade: websocket header to let the server know that the client wants the connection to use a WebSocket and not HTTP. If the server supports WebSockets, and the request headers are valid, the server is required to send a 101 reply to let the client know that the server is switching the connection over to a WebSocket for the duration of the connection. Any other reply other than a 3xx redirect means means the server does not recognize or allow the Upgrade request on that URL.
Related
I created a TLS server that authenticates the client, reads the client request and answers appropriately.
I want to test how my server reacts to bad tls handshake requests, errors and alerts. Is there a client that can test this on my server?
Thanks in advance
I have configured JBoss with HTTPS connector only. Now I have problem, that in case I'm using HTTP request to HTTPS connector, it returns page with one ASCII character, instead of some error page, for example 505 or something else what can user inform, about invalid request.
There is no used Apache nor any other web server, where some rules for URL rewriting could apply. Also often used change in web.xml with <transport-guarantee>CONFIDENTIAL</transport-guarantee> tag do not solve this problem, as there must be HTTP request, which is then redirected to HTTPS based on "redirectPort" param in connector configuration and in this case there is not plan to use any other port and it is not possible to combine HTTP and HTTPS listener together on one port.
Is there some way how to configure SSL listener, that way, that it refuse HTTP request, or automatically change to HTTPS?
JBoss 5.1.0
Your browser uses HTTP to talk to server, but on the server side is the security layer (around the HTTP) and it wants to do a SSL/TLS handshake. So the communication fails because client doesn't know about the security on the other side.
The client (browser) receives error message (binary data) from server. The client doesn't know what to do with them, so it presents them to a user as a web page content.
RFC-5246 states:
Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection.
Undertow - a new web server in WildFly - is able to do HTTP Upgrade. But I'm not sure if the upgrade to SSL/TLS is already supported. Nevertheless, the problem with this scenario could be on the browser side.
Based on the documentation Apache allows to request a client cert authentication for one directory and don't request it for another directory.
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients
How is it possible?
I assumed that first TLS/SSL does a handshake (including client certificate validation) and only after it, HTTP request is sent over secured channel. And this HTTP request contains a URL.
So, it looks like to get a URL (a diretory) you need to do (or skip) client certificate authentication.
So, it's not clear for me, how can Apache check URL first and decide later whether to request a client cert authentication or not.
It uses SSL/TLS renegotiation: the server sends a TLS Hello Request message to ask the client to trigger a new handshake by sending a new Client Hello message (and this time the server will send a Certificate Request after its Server Hello message).
The Hello Request message could in principle happen at any time during the HTTP exchange. For this particular feature, the server sends it just after receiving the request (therefore knowing which resource was requested), but before sending its response.
I have an api (running in a jetty instance) where I use two-legged oauth protocol to give access to the clients. I wrote a simple java client (using oauth-signpost) to connect to the api and the connection is successful.
I would like to put the api behind an apache http server. The apache http server is configured to forward request to api.
The following works:
(without oauth) Client ---> Apache HTTP Server --> Jetty
(with oauth) Client ---> Jetty
The following doesn't work:
(with oauth) Client ---> Apache HTTP Server ---> Jetty
I receive the following error message
"Invalid signature for signature method HMAC-SHA1"
Has any of you faced this issue? Is it possible to sign the request but without the hostname and port?
Thank you.
I had a similar problem. The problem I found was that the OAuth signature and the OAuth header block need to have the Jetty URL, not the Apache URL.
I had to modify my code to pass along two URLs. The URL I was sending the request to (Apache) and the URL of the resource on the final system (Jetty URL).
I have recently started my job as web application backend developer. I am bit stuck in understanding lifecycle of a Http request.
What I understood is
Every Http request first contacts a DNS server which resolves the request URL domain to a IP address.
After fetching the Webserver IP address request is forwarded to it(via PUT request). A webserver like apache handles this request and forwards this to application which has to handle this.
After this I am lost with
How response is sent by the application to the user who requested it and will Apcache involved in this?
Can I see the entire flow in my browser with some debugging tools?
Can someone refer some links to understand this in depth?
I think you are a bit wrong on your understanding of it.
If you go to www.google.com (not using any forms, just wanting the site), this is what happens:
First the browser needs to translate www.google.com to an IP address if it does not already know it. If it knows it, nothing happens at this point. If it does not know it, it contacts a DNS server to resolve the name.
Then browser will open a TCP connection to the IP address of www.google.com and send a HTTP GET request over. In this example it will be
GET / HTTP/1.1 Host: www.google.com
The server software will get this HTTP request. It will somehow generate a HTTP response and send that back trough the TCP connection. How the server does this is server software dependent. You can for example plug in application code in Apache, or just make Apache return a file from the filesystem. PHP is an application called by some software, which then generates the response sent to the browser. When the response is sent, in HTTP version 1.0 the connection is closed. HTTP 1.1 can have persistent connections though.
When the browser gets the response, it typically renders it on screen. The HTTP request is now done. A click on "search" will send a new request to the server.
GET, PUT, POST, DELETE and others are HTTP request methods. They have special meaning which you can see in the RFC.
Cookies are commonly used to identify the same user across multiple HTTP requests, called sessions. Therefore these cookies are called session cookies
You can debug the communication by using a network sniffer tool, for example Wireshark. Firefox has a third party plugin called Tamper Data that can change the request before they are sent to the server.
The HTTP RFC is a good source of how it all works.
while server receives the request from browser , the browser will be binded to some port on the host , ip address and port number of browser will be attached with the request that sends to server. server sends the responce to the ip address and port number
This is among the popular interview questions asked in various product based companies.
HTTP Is a request-response protocol. For example, a user agent initiates a request to a server, typically by opening a TCP/IP connection to a particular port on a host (port 80 by default). The request itself comprises:
a request line,
a set of request headers, and
an entity.
An HTTP server listening on that port waits for the client to send a request message. Upon receiving the request, the server sends a response that comprises:
a status line,
a set of response headers, and
an entity.
The entity in the request or response can be thought of simply as the payload, which may be binary data. The other items are readable ASCII characters. When the response has been completed, either the browser or the server may terminate the TCP/IP connection, or the browser can send another request.
I found this resource very helpful in understanding the steps taken during the HTTP lifecycle : quite interesting actually though, wasn't aware of all the intermediate steps especially w/the cache checking when determining the IP Address of a URL.
https://medium.com/#maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a