This question already has an answer here:
How can I integrate socket.io on Karate
(1 answer)
Closed 1 year ago.
Got the following exception when connecting to a WebSocket server with karate.webSocket():
org.graalvm.polyglot.PolyglotException: karate.io.netty.handler.codec.CodecException: invalid WebSocket Extension handshake for "permessage-deflate; server_no_context_takeover; client_no_context_takeover"
- com.intuit.karate.http.WebSocketClient.<init>(WebSocketClient.java:144)
- com.intuit.karate.core.ScenarioEngine.webSocket(ScenarioEngine.java:731)
- com.intuit.karate.core.ScenarioBridge.webSocket(ScenarioBridge.java:861)
The server response has the header
Sec-WebSocket-Extensions: permessage-deflate; server_no_context_takeover; client_no_context_takeover
According to the spec https://www.rfc-editor.org/rfc/rfc7692#section-7.1.1.1, a server may include this in the response header.
Tried to specify the same header in the options but still failed.
Is there a way to work around this?
It certainly can be a case we don't support yet. It would be great if you can follow this process and hopefully you can find a public end-point to simulate or try to create a local way - ideally via java / netty or you can use some JS lib etc if that's more convenient.
Instructions: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
Of course if you can also provide pointers or a PR, nothing like it. Here is an example of a similar conversation in the past: Is there a way to use custom headers when opening WebSocket connection?
Related
I have a fundamental question. I cannot figure out how to get the MockServer to log (like outlined in this inquiryPactNet - HttpPost Test Fails with 500 internal server error ). If I had that information I may be able to determine my problem. How was that enabled?
I am running Net 6, using the Pact-Net NuGet libraries and PactBuilderV3
I am running into the same issue as the above question link. I cannot Post or GET with a body in my consumer tests.
This question already has an answer here:
Karate DSL: Getting connection timeout error
(1 answer)
Closed 1 year ago.
I'm trying with Karate behind my office network which is using proxy. But the configure statement didn't work. In home network. it works perfectly fine.
The configure statement : didn't work for our proxy. karate.configure('proxy', 'https:/my.proxy.host:8080');
As you can see from these issues #502 and this other Stack Overflow question, this works for others. So you will have to figure this out and it will help everyone if you debug this on the Java side if possible. Maybe you are missing authentication for your environment.
You can try switching to karate-jersey from karate-apache or vice-versa and see if that changes anything. Else unless you provide a way to replicate, we can't help - but this is indeed difficult for a proxy: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
I have problem with android studio, I was working with it after update to 3.1.3 i give below error:
Could not GET
'https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/3.1.3/gradle-3.1.3.pom'.
Received status code 400 from server: Bad Request
I could download this file manually but android studio can't.
I test several way and use proxy but I can't get answer.
At last today i could solve problem, this error related to your connection i could solve this with proxy setting. google filter our Iran IP and could detect some proxy and you must use good proxy to pass it.
I'm getting the thing, but with a 407 error.
Could not GET 'https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/3.1.3/gradle-3.1.3.pom'. Received status code 407 from server: Proxy Authentication Required
"I could download this file manually but android studio can't.
I test several way and use proxy but I can't get answer."
Same here.
I'm trying to retrieve data from an open data api. I have downloaded the certificate from the site and imported it into STRUST (SSL Client Anonymous).
Then I created a HTTP connection to external server in SM59. In the beginning it worked fine, until last week when the api changed its URL and so its DNS.
Of course it could no longer be reached by the current host. So I did above steps again for the new URL (changed everything accordingly like hostname etc. in SM59), but this time I receive following error:
SSL handshake with 'hostname:port' failed: SSSLERR_CONN_CLOSED (-10)#Remote
Peer has closed the network connection##SapSSLSessionStartNB()==SSSLERR_CONN_CLOSED##
Anyone has an idea on how to solve this?
On another forum someone helped me solve the problem. He pointed me out that the problem lies with SNI see: https://security.stackexchange.com/questions/101965/ssl3-error-when-requesting-connection-using-tls-1-2/102018#102018
https://en.wikipedia.org/wiki/Server_Name_Indication
To solve this problem you need to add following parameter: icm/HTTPS/client_sni_enabled and set it to TRUE on the DEFAULT profile. Afterwards you need to restart the application server in order to activate the effects of the parameter.
Link to the full question on SCN: https://answers.sap.com/questions/473015/sap-ssl-handshake-failed.html
EDIT:
I came across this error again later on, but this time it seemed that the error was caused because we used a certificate with TLS 1.2 which was not supported by our system. You can check this link: https://launchpad.support.sap.com/#/notes/510007 we implemented number 7 to fix this.
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server