The Websocket or XHR transport works just fine.
But not the Flashsocket.
The console shows this:
debug - setting request GET /socket.io/1/flashsocket/kavSuw7LSfrHmQBM1C8D
debug - set heartbeat interval for client kavSuw7LSfrHmQBM1C8D
debug - client authorized for
debug - client authorized
info - handshake authorized UPai64qwBoTlGL2X1C8E
then nothing more... I set the program to emit msg every second, nothing sent.
Then I use chrome to access http://domain.com:10843/, it shows this:
<cross-domain-policy>
<allow-access-from domain="*" to-ports="*"/>
</cross-domain-policy>
I think it is not blocked... So what's wrong here?
PS. Server is Windows Server 2008
Try testing on IE8 or 9. It has been noted that flashsocket will not work on Chrome even if it is the only transport listed. Use ["websocket","flashsocket"] for best results, and if you get a websocket when you weren't expecting one, consider it a happy surprise :-).
Related
I'm able to verify the webhook using glitch from the getting started:
https://glitch.com/edit/?fbclid=IwAR2YTjZuGGM9Hi6T_v1eZh_nV6_HY3RYn_8lll4gY1REa_bJy6ZAuq6tkKQ#!/whatsapp-cloud-api-echo-bot
my local server (in a subdomain with https enabled) has the same behavior as glitch and show "WEBHOOK_VERIFIED" on the log for the request:
/webhook?hub.mode=subscribe&hub.verify_token=xpto123&hub.challenge=123
but when try to verify my local server the request from meta does not reach the server.
chrome showing that the connection to the server is secured
After more tests I found that my local server was been blocked by the ISP, understood it after test with another connection.
I made my own server and had tried ngrok and other programs to run it from local host with https redirect but whatsapp doesn't allow the use of those programs.
In the end, my error was that the URL HAS to end in /webhook or else, it won't even send the request. Then it'll send a GET request and you have to return the hub.challenge query param after making sure that the provided token from them is the one you set up. This is my code using NodeJS
if(req.query['hub.verify_token'] === process.env.VERIFY_TOKEN) return res.status(200).send(req.query['hub.challenge'])
I want connection to a websocket server wss://fm.missevan.com:3016/ws。i use online websocket tool http://www.websocket-test.com to do it, but in edge browser, it's response is ok and in chrome ,the response is 403 forbidden.
Actually, i use GO language to connection wss://fm.missevan.com:3016/ws,I tried many websocket library but all failed.
I checked the request header of connected browser, there are no special fields. so who can analyze the reason of this, thanks
I am using the Postman native app on Windows 10 and am struggling with trying to capture https requests. Postman's Documentation for this is for Mac and not Windows.
In particular, I am working on a web application that creates a session cookie upon login that needs to be included in most requests in order to be authorized. When I was using the Chrome App, Postman Interceptor achieved this (see https://stackoverflow.com/a/32436131/3816779).
Here's what I've tried so far:
Turn on the Proxy in Postman with port 5555.
Configured windows to send http and https requests through Postman's proxy server (127.0.0.1:5555).
This allows http requests to be captured in Postman
But when trying to connect to https sites, I get an error
Here are my Postman settings if that helps.
Update I ended up switching back to the Chrome App, which uses the "Interceptor" instead of a "Proxy Server" to capture traffic.
Unfortunately, capture https requests with postman native app is impossible in some case according to the official doc: Capturing HTTP requests
Note: for the Postman native apps, request captures over HTTPS will not work if the website has HSTS enabled. Most websites have this check in place.
Postman's proxy now supports HTTPS traffic - https://blog.postman.com/postmans-proxy-now-fully-supports-https-endpoints/
Once you install a CA certificate that Postman generates for your installation, capturing HTTPS requests should be seamless.
Disclaimer: I work at Postman
With Google Chrome i don't know how to fix the issue. But you can use to open the web page for example IE..
EDIT:
Or MAYBE you can start Google Chrome with parameter --ignore-certificate-errors to ignore the error message.
Postman Interceptor is available for Postman native apps which supports both features:
1. Capturing requests
2. Syncing cookies
Learn more here.
Just check HTTPS in setting and will work for you
I have a web application that communicates with the server with AJAX. I am using https and SSL and keep-alive is set to 10 seconds.
Sometimes the user is sending a request to the server exactly when the keep-alive time expires. When this happens a new SSL session is created. This is all fine.
After this happens, the browser (Internet Explorer 11) is resending the AJAX request.
But now strange things happens. The browser is only sending the headers of the request. No body. The server first waits for a body that never arrives. Finally the server is aborting the request and the client gets a exception with http status 0 with message: Network error.
Some say this is normal behavior when using SSL and keep-alive and that this must be handled in the webb application. Other say this is a not correct behavior in Internet Explorer 11.
All I can see is that the server cant reuse a body of a request sent on a previous SSL session. The browser need to resend the entire request, but this is not happening.
If I catch the exception in the application and resends the request to the server, everything is working again. But it feels very strange to catch all http=0 in and resending them. Could also be dangerous from a application point of view.
The application only works in IE, so I cant compare with Chrome and FF.
My question is: Is this normal behavior or have I perhaps some incorrect configuration in the browser or on the webbserver?
When the server closes a connection at exactly the same time as a new request on a keep alive connection was sent, then it is not clear if the server received the request and acted on it or not. Therefor only requests which are considered idempotent (i.e. not change anything on the server) should be automatically retried by the client. GET and HEAD are considered idempotent while POST not.
Thus if the client automatically retries a GET or HEAD this would be correct behavior. Retrying a POST would be bad. Resubmitting a request without a body which originally had a body (like you claim but don't prove) would be a bug.
I've just come across a problem relating to IE that there seems to be virtually no documentation about on the 'Net - only a few people asking similar questions.
When I use jQuery (1.4.2) to send a POST request to my server (to which the server responds by sending JSON data), I occasionally get XHR 408 errors (meaning that the server timed out while waiting for the client to finish its request), and (less frequently), XHR 12152 errors (I don't know what these signify). There does not seem to be a pattern to this.
This only occurs in IE (version 8 - I haven't tried other versions, though I can confirm that the problem occurs on two different installations). Safari and Opera seem fine.
This doesn't seem to be a problem with GET requests.
If anyone has any thoughts on the matter, I'd be very grateful.
When you see IE returning things in status that clearly aren't HTTP status codes, they're actually Windows error numbers, typically from WinInet.
12152 ERROR_HTTP_INVALID_SERVER_RESPONSE would seem to confirm the 408's implication that there's a low-level HTTP-syntax problem between your browser and the server. Traditionally this has been a problem with the ActiveX implementation of XMLHttpRequest and keep-alives in HTTPS, but the exact cause is rather murky.
You could perhaps try having the server set Connection: close on XMLHttpRequests that come from IE, see if that helps? This will affect performance, unfortunately.
I solved it by adding "Connection: close" to ajax header also.
There is no need to add "Connection: close" to the response header from the server.
I have tested firing 1,000 requests.