Does anyone know how to use utls for pre_shared_key extension.
Btw, i got the same problem with extension 34 which i am using the same way but different id as 34.
What i am currently using in my code:
case "41":
tlsext = &tls.GenericExtension{Id: 41}
My Request error from Golang script to server sniffed
Original Request from chrome to server sniffed
Related
I am programming an HTTP request parser and I would like to see the string Chrome sends whenever a resource is requested (that may be a website or content on the website). I know that you can go into the Chrome developer tools under the network tab and then see all the details about the requests sent. However, these details are already parsed into categories and I would like a raw string representation of the HTTP request. Is there any way to get just that and, if not, could you recommend any tool or website to get a bunch of dummy HTTP requests to debug my parser?
There is no built in function to acquire the raw http request string in Chrome. Request parameters can either be optained by using the network tab in the developer tools or by using chrome://net-export.
However, external tools such as Fiddler can obtain the raw http requests send and responses recieved by your computer. Just select a request on the left and the raw output format.
I have an issue when trying to do a simple POST request to some internal endpoint using akka-http. When this piece of code is executed:
for {
request <- Marshal(merchantTransactionRequest).to[RequestEntity]
response <- Http().singleRequest(
HttpRequest(
method = HttpMethods.POST,
uri = "http://foo/bar:8080",
entity = request.withContentType(ContentTypes.`application/json`)
)
)
...
} yield ...
I get greeted with the following error:
akka.http.scaladsl.model.IllegalResponseException: The server-side HTTP version is not supported
at akka.http.impl.engine.client.OutgoingConnectionBlueprint$PrepareResponse$$anon$1.onPush(OutgoingConnectionBlueprint.scala:191)
...
which is immediately preceded by the following log:
[0] </10.0.0.135:42610->foo:8080> pushing request to connection: POST bar Strict(508 bytes)
As part of my debugging journey, I executed the same query to the endpoint using curl, which magically succeeded (and responds with HTTP/1.1). Since HttpRequest(...) defaults to using protocol = HttpProtocols.`HTTP/1.1`, it is my suspicion that somehow the HTTP version negotiated between akka-http and this other endpoint is incorrect.
Is it possible to somehow enforce a HTTP version when akka-http does a POST? Or any other clue as to why curl succeeds doing the POST, while akka-http does not? Note that problem only occurs while doing POST's, not GET's.
It turned out the problem had a very strange solution: Instead of connecting to directly connecting to the other endpoint through address http://foo/bar:8080 (using our internal DNS resolver), we connected indirectly to the endpoint using https://our-domain.com:443. Everything worked as expected in that case. It seems that akka-http is somehow troubled by the absence of a TLD.
I am working on a project which sends GPS longtitude and latitude to a server using Http POST method. I use GPRS of sim908 module and AT+Commands to communicate with this module.
Here are the commands related to Http Post:
AT+HTTPPARA="URL","http://'server'/'path':tcpPort'"
AT+HTTPACTION=1
AT+HTTPDATA= 'size','time'
The first command is used to set http parameters:
'server' = FQDN or IP address
'path' = path of file or directoy
'tcpPort' = default is 80
The second commands tells the module whether to use GET or POST method which is POST here.
The third one is used to recieve server response:
'size' = number of characters to read
'time' = set enough time to input all data with length of 'size'
I know how to send data using GET method. I must put a string like: "?var1=value1&var2=value2" at the end of the url. Here is an example: "http://www.example.com/test/getdata.php?TI=12.1&TO=22.2&TR=33.3"
But how is the POST method? Could anyone help me please?
Thanks alot.
[SOLVED]:
SIM908 does actually support post even though it is poorly documented:
AT+HTTPINIT
AT+HTTPPARA="CID",1
AT+HTTPPARA="URL","http://108.167.133.20/.../index.php"
NB*** AT+HTTPDATA=, ****NB
Wait for DOWNLOAD response then send data (bytes needs to be exact)
AT+HTTPACTION=1
AT+HTTPREAD=1,100000
I need to modify the ws url before it establishes a websocket connection.
I'm using #ManagedService in the server code and subscribing from client side using $.atmosphere.subscribe(request).
I've the following setup:
Cyberoam firewall --> Apache httpd(mod_proxy_ajp,mod_jk for load balancing) --> Glassfish
Primary Transport --> WebSocket
Fallback Transport --> long-polling
Problem I'm facing:
The Cyberoam firewall is having a limitation (in WAF) that the max characters in GET URL cannot exceeds 50 chars. But when I hit the subscribe in atmosphere, it is constructing the URL with all the X-Atmosphere-.. params along with it.
For e.g ws://localhost:8080/chat?X-Atmosphere-tracking-id=5ebed4c5-0b90-4166-88b2-9f273719ab75&X-Atmosphere-Framework=2.2.1-jquery&X-Atmosphere-Transport=websocket&Content-Type=application/json&X-atmo-protocol=true") which clearly exceeds the allowable limits.
I just need to know whether I can somehow construct the URL in my server code appending all the necessary headers and params before it connects?
Yes, I have set the attachHeadersAsQueryString:false while making the initial request, and obviously it doesn't connect with missing headers information while doing a WebSocket connection.
Any suggestions/thoughts would be greatly appreciated.
Thank You.
Use request.attachHeadersAsQueryString = false so mo query string will be passed. You may need to upgrade to the latest version of Javascript
https://github.com/Atmosphere/atmosphere-javascript
-- Jeanfrancois (Atmosphere's lead)
The flow is SAP NWAS 7/Java AS ---> Apigee On Premise--->Apigee OnCloud -----> Backend. and back.
Backend is posting a response of appx 17 MB back. I have streaming enabled both on cloud and on premise Apigee. But the sap NWAS client states that only partial response is received .
When we invoke from POSTMAN however, we are getting complete response.
Please suggest where the problem can be?
Since Postman works fine for you, it seems like it might be a problem on the client side. So, it's possible that the client requires more info on the response in order to be able to display the content e.g. Content-Type header. Another way to troubleshoot this issue is to send a cURL command to the resource in Apigee and store it in the filesystem to validate that not only Postman can parse the response. e.g.
curl http://yourresourcehere/images/12344 > img12344.png