How to print the WebSocket HTTP Upgrade Request? - boost

Reference: websocket_client_sync.cpp
Table 1.30. WebSocket HTTP Upgrade Request
GET / HTTP/1.1
Host: www.example.com
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Key: 2pGeTR0DsE4dfZs2pH+8MA==
Sec-WebSocket-Version: 13
User-Agent: Boost.Beast/216
Question> Based on the example websocket_client_sync.cpp, which function is used to send a HTTP Upgrade Request similar as the one shown above and how can I print the request shown above?
Thank you

This is a duplicate, but I can't mark it as such because this answer was never accepted¹:
boost async ws server checking client information
In short use the overload of accept that that takes a request object that you have previously read.
The linked answer has a complete live demo.
¹ answering on Stack overflow can be pretty thankless at times
UPDATE
To the comment, I apologize for missing the client/server distinction initially. The client has a similar overload on handshake that allows you to inspect the upgrade response:
http::response<http::string_body> res;
ws.handshake(res, host, "/");
std::cout << res;
Printing e.g.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: /wp5bsjYquNsAIhi4lKoIuDm0TY=
However, the request is not directly exposed. I suppose it's best monitored with a network packet sniffer or from the server side. If the goal is to manipulate the upgrade request, you should use a RequestDecorator.
PS: I just checked and the request decorator is applied nearly-at-the-end (although some things related to per-message-deflate might be added on later in the handshake_op). So you might be content with just supplying a decorator that inspects the request:
http::response<http::string_body> res;
ws.set_option(websocket::stream_base::decorator(
[](http::request<http::empty_body>& req) {
std::cout << "--- Upgrade request: " << req << std::endl;
}));
ws.handshake(res, host, "/");
std::cout << "--- Upgrade response: " << res << std::endl;
Which prints e.g.
--- Upgrade request: GET / HTTP/1.1
Host: localhost:10000
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Key: Quyn+IEvycAhcRtlvPIS4A==
Sec-WebSocket-Version: 13
--- Upgrade response: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: aRDrnkHhNfaPqGdsisX51rjj+fI=

Related

Jetty upgrade (9.2.24 -> 9.4.10) fails with websocket (UpgradeException)

I am in the process of upgrading our jetty from 9.2.24 to 9.4.10, for an app that works extensively with websockets.
I have an existing test (junit) that sets embedded jetty, registers to it rest resource and websocket servlet and then tests to see if they can be accessed.
The test works perfectly well when jetty is at version 9.2.24. An attempt to move to version 9.4.10 with the very same code fails with
java.io.IOException: Connect failure
at org.eclipse.jetty.websocket.jsr356.ClientContainer.connect(ClientContainer.java:232)
at org.eclipse.jetty.websocket.jsr356.ClientContainer.connectToServer(ClientContainer.java:255)
...
Caused by: org.eclipse.jetty.websocket.api.UpgradeException: 400 Bad Request
at org.eclipse.jetty.websocket.client.WebSocketUpgradeRequest.onComplete(WebSocketUpgradeRequest.java:522)
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193)
The websocket definition on server side is based o JSR356 spec (i.e. extends EndPoint). The websocket client used to access the websocket is also based on the javax.websocket (i.e. ContainerProvider.getWebSocketContainer().connectToServer(Endpoint instance...)) - where the websocket container is effectively a jetty one...
The server sets up perfectly. The problem is only when trying to access the websocket. I have debugged and could not find any difference in the way the client initiates and sends the websocket request. In particular the request has a the 'upgrade' header set to 'websocket' as expected.
So I could only assume that the problem is in the way the websocket resource is registered in the embedded jetty. I have debugged the working flow (with 9.2.24) and found the most early place where the connection is accepted in jetty (one of the selector threads at AbstractConnection). but from some reason I am not getting to that point for the websocket when working with 9.4.10
I have read several resources and SO question (e.g. this question) and could not found anything that will help me with this problem.
I am in a dead end.
Here is the key elements in the relevant code of the server registration (I also have another rest resource along with the websocket one):
// web socket
ServletContextHandler wsContext = new ServletContextHandler(ServletContextHandler.SESSIONS);
wsContext.setContextPath("/ws_api");
ServerContainer container = WebSocketServerContainerInitializer.configureContext(servletContextHandler);
container.addEndpoint(new BasicServerEndpointConfig(container.getClient(), endpointClassObject, path)
// rest handler
ServletContextHandler restContext = new ServletContextHandler(ServletContextHandler.SESSIONS);
restContext.setContextPath("/rest_api");
...
ServletHolder sh = new ServletHolder(...);
restContext.addServlet(sh, "/*");
final HandlerList handlers = new HandlerList();
handlers.setHandlers(new Handler[]{wsContext, restContext, new DefaultHandler()});
server.setHandler(handlers);
Help...
Update (additional information per Joakim Erdfelt request):
I am at class HTTPConnection class, in BP at onComplete() method, fetching the request headers from the _channel._fields object I get:
The response object's status is 200 (and not 101 as expected):
My endpoint object is part of a large inheritance chain. It is full of boilerplate business logic code that I need to remove before I can upload it, but in the root stands the javax.websocket.Endpont class, where we implemented only the onOpen(Session session, EndpointConfig config) method. I am not getting to that method when debugging, seems to fail long before...
Your request headers looks like this ...
Accept: application/json, application/*+json
Accept-Encoding: gzip
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json
Host: 127.0.0.1:8080
Pragma: no-cache
Sec-WebSocket-Key: sMQPm6Cf00itLII3QBb4w==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Java/1.8.0_144
That is an invalid WebSocket Upgrade Request.
The most glaring omission is
Connection: upgrade
But there's also other fields that a compliant WebSocket Client would never set.
Content-Type: application/json
Accept: application/json, application/*+json
Accept-Encoding: gzip

MQTT over Websocket request / x-amzn-ErrorType: ForbiddenException

I am using ESP8266-Websocket, aws-sdk-arduino(cleaned branch) and pubsubclient to try to comunicate with aws iot mqtt service using websockets.
My question is about the first connection request. I am using this browser app as reference https://github.com/awslabs/aws-iot-examples and the sign code from aws-sdk-arduino (that works fine calling the aws iot restful api)
My request was this (after connect to the endpoint at 443 port):
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
host: ENDPOINT.iot.us-west-2.amazonaws.com
Connection: Upgrade
Upgrade: websocket
Origin: file://
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: D2alJOyUkBlR+8yhv2UBLg==
Sec-WebSocket-Protocol: mqtt
but I keep getting
HTTP/1.1 403 Forbidden
content-type: application/json
content-length: 241
date: Fri, 18 Mar 2016 18:34:57 GMT
x-amzn-RequestId: f2edfe83-1bbc-4481-97e0-39ccfc4d1c2f
connection: Keep-Alive
x-amzn-ErrorType: ForbiddenException:
am i missing some request header parameter? is there anyway to get a better feedback from x-amzn-ErrorType: ForbiddenException? am i messing up in the sign process? (even though it works for rest call)
Yeah, I've finally got response status 101 switching protocols \o/
when you are building the request, it must be:
GET /mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
instead of
GET wss://ENDPOINT.iot.us-west-2.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AWSKEY%2F20160318%2Fus-west-2%2Fiotdevicegateway%2Faws4_request&X-Amz-Date=20160318T183246Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=a1f0d7b58983f9dff7e3bf6cab062db3243ebafc990803a018c6a23433891404 HTTP/1.1
the js example that I was following was using the full path. When I got the request built by chrome (throught developer tools) the path was full as well. Just after use firebug I got the real request that browser was sending to the server (with short path).
now I can continue to try the solution (mqtt over websockets at esp8266) :-) if it works, I will share the code ;-)

Arduino WebSocketClient Sec-WebSocket-Key Error

I built a WebSocket server using WebSocket-Node and the client is an Arduino with an Ethernet shield using the library WebsocketClient from krohling.
The first issue I had was that even the example from the WebsocketClient library didn't return a response from the echo.websocket.org server.
Since the Arduino's Serial monitor didn't give me errors, I added a Serial.print on the handshake section of the library's code to debug the error and I got the following:
HTTP/1.1 400 Bad Request
Server: Kaazing Gateway
Date: Tue, 07 May 2013 05:11:21 GMT
Access-Control-Allow-Origin: ArduinoWebSocketClient
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol
Content-Type: text/html
Content-Length: 63
Connection: Keep-Alive
Then, I tested it with the WebSocket-Node server I created and got the following on the Serial monitor:
HTTP/1.1 400 Bad Request
Connection: close
X-WebSocket-Reject-Reason: Client must provide a value for Sec-WebSocket-Key.
Am I doing something wrong or does the WebsocketClient library need to be updated?
I haven't been lucky to find a better/newer Arduino Websocket client library. Does anyone know about one I could use?
Thanks a lot!

How to add basic auth header in autobahn client tool

I want to add basic auth header in the autobahn client tool. How can I achieve that?
Current request
GET / HTTP/1.1
User-Agent: AutobahnPython/0.5.2
Host: 10.35.34.172:9000
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: 1U4OeBs60qkmk1V/8voLOw==
Sec-WebSocket-Version: 8
Request I need:
GET / HTTP/1.1
User-Agent: AutobahnPython/0.5.2
Host: 10.35.34.172:9000
Authorization: Basic TXlMb2NhdGlvbkFwcDpNeUxvY2F0aW9uQXBwMTIz
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: 1U4OeBs60qkmk1V/8voLOw==
Sec-WebSocket-Version: 8
Note: I don't want autobahn server to authenticate the client.
My scenario is autobahn client --> my server --> autobahn server.
My server will take care of extracting the authorization header and then invoke the autobahn server.
I have implemented options to send custom HTTP headers for both AutobahnPython client and server. You need to use the latest AutobahnPython on GitHub (master branch).
A client can send headers by providing a headers keyword argument during construction of the WebSocketClientFactory or set headers via setSessionParameters.
A server can send headers similar to client, and additionally specify headers when returning from onConnect.
Here is a complete example.
Disclaimer: I am original author of Autobahn and work for Tavendo.

Problem with webclient: Expectation failed?

I have a custom Http Handler which manipulates HTTP POST and GET. I got the project working on a seperate isolated server now need to put it in production...
using (var client = new WebClient())
{
client.Credentials = CredentialCache.DefaultCredentials;
client.UploadFile("serverlocation:port", fileToUpload);
}
For some reason now when using client.UploadFile("", file); i.e. forcing the HTTP POST
System.Net.WebException: The remote server returned an error: (417) Expectation failed.
at System.Net.WebClient.UploadFile(Uri address, String method, String fileName)
What could this be? I know the code works, so what else? Maybe the server blocks HTTP POST requests?
I have tried adding:
ServicePointManager.Expect100Continue = false;
But have had no success though i'm not 100% sure where this code should before, I assume before i'm using the WebClient
Edit 0 :
I have just read the following:
Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client SHOULD NOT wait
for an indefinite period before sending the request body.
I believe this request is going through a proxy, which may have something to do with the issue.
Edit 1:
Believe this problem has to be with 100-continue because, using fiddler to see exactly what my application is sending with WebClient.UploadFile shows this:
POST http://XXX.XXX.XXX.XXX:8091/file.myhandledextension HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------8ccd1eb03f78bc2
Host: XXX.XXX.XXX.XXX:8091
Content-Length: 4492
Expect: 100-continue
Despite having put that line: ServicePointManager.Expect100Continue = false; before the using statement. I don't think this line actually works.
I ended up solving this by putting the ServicePointManager.Expect100Continue = false; in the constructor for the calling WebClient class.
Then I used Fiddler to examine the POST request to ensure Expect: 100-continue was not in the request anymore.

Resources