`▒▒+Q4▒▒POST/nspversion=1.0&op=notify&sid=966ca56d500083a311eab9c8af564b1a` `HTTP/1.0^M`
User-Agent: mealso/1.0 (I; en-US)^M
Host: google.com:5001^M
X-Tellme-FetchGUID: 870ee784-b9da-11ea-d9ae-00005e0001ca^M
Content-Type: text/xml^M
Content-Length: 1592^M
X-Tellme-DID: 6247b3b10d76de4facf9ff7bb4c4c7ea^M
this code is present in .pcap file of tcpdump, what is the functionality of this code exactly?
This is going to be in the HTTP layer of some packet in the packet capture.
All of these are HTTP headers, and not code per se. User-Agent, Host, Content-Type, and Content-Length are all HTTP request headers, so this is an HTTP request. X-TellmeFetchGUID and X-Tellme-DID are non-standard headers, and you can tell this because they start with X-.
Related
I tried to send cookies like this this:
PUT http://localhost:8080/platform/rs2/processes/data/4252
Accept: */*
Cache-Control: no-cache
Cookie: {{"TOKEN": "eyJzZXNzaW9uSWQiOiIyMTg2NTQ0Mi0zZDAxLTQ0ZWUtYTFjZC02MjI2MzllYTZhZGEiLCJjdXJyZW50VXNlcklkIjoiMjgxNDk2OTktYjNhMi00MzY1LWE4ZjAtMjYyMzljOTlmMWRkIn0"}}
But in fact they don't come to the server-side.
In 2021 version of IntelliJ you can send cookies with the request like this:
POST url
Accept: application/json
Cookie: name=value; name2=value2
Ref syntax: https://developer.mozilla.org/en/docs/Web/HTTP/Headers/Cookie
There is no need to specify cookie, there is a file http-client.cookies used for recive cookies. If your server-side response with cookie , it would be recorded in this file.
and will be sent to your server-side automatically
https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html#viewingResponse
I have a WCF service which I make API requests to.
This API call returns a JSON response object and also is able to return it in GZIP compression as well when "gzip" value is used in "Accept-Encoding" header.
The problem is when I try to get the response in GZIP, Postman shows "Could not get any response" although I see response and response's content are OK (200 status code) in Fiddler and can easily decompress the response content in my C# client.
I took a look in Postman Console but all I see is "Error: incorrect header check".
I hardly tried to find any documentation regarding this header check but couldn't find any.
These are the request headers:
POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close
These are the response headers:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close
The only thing I suspect is wrong is this message from Fiddler:
I integrated this code into mine in order to use GZIP in WCF.
https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection
Basically, it captures the response before returning to client and use GZipStream for compression.
I got the same issue, I added the following header to fix this issue.
Accept-Encoding : *
I was able to solve a similar issue by using the header Accept-Encoding: */* or if you want to be specific do Accept-Encoding: */* that way the HTTP client will be able to process the response based on the type of encoding received, in the case of a gzip, it will decode the response and show it as normal text.
For me, I removed 'Accept-Encoding' in the request header.
I got this issue when the REST service was returning a zip content (aka. WinZip format). I solved the error by compressing the data using 7zip to produce true gzip format.
I am trying to send a post request though an api. The call requires:
content-type: multipart/form-data; boundary=[boundary_number]
I have used Charles HTTP proxy to watch see what headers/content I need to send.
My Request: (basically copied from Charles' multipart section)
--324a08fa-6b58-424a-a1ad-691123d9d04b
Content-Disposition: form-data; name="message[body]"
Content-Transfer-Encoding: binary
Content-Type: text/plain; charset=utf-8
Content-Length: 5
Text!
--324a08fa-6b58-424a-a1ad-691123d9d04b--
** My Headers:**
My Result:
When I post this in postman, the response just displays 'Loading'
I can't seem to satisfy the content I was wondering if anyone can point me in the right direction.
Any help would be greatly appreciated!
Cheers!
The response is not as expected because the Content-Length of HTTP request body is incorrect. It should be 240, not 238.
For HTTP request in Charles screenshot, the message[body] data is qqq, which is also indicated by Content-Length: 3. However, in your HTTP request in postman, the message[body] data is Text!. While its own Content-length is correct (5), the Content-length of the whole request body is not changed accordingly -- it's still 238, which should be increased to 240.
Is it possible to send gzip'd HTTP POST requests in Paw?
I have accept-encoding, content-encoding set to gzip but it seems to be not enough to get it to work.
POST / HTTP/1.1
Content-Type: application/json
Content-Encoding: gzip
Accept: application/json
Accept-Encoding: gzip
X-Protocol-Version: 2
User-Agent: test-ua
Host: host123:8080
Connection: close
Content-Length: 120
[{"user-id":"123","p-id":"1"}]
I can confirm that. It is not possible at the moment to send gzip'ed body automatically.
If you use "Content-Encoding: gzip" you must gzip the body and drop the file into Paw. Paw is sending the gzip'ed body without any issue. I am using Paw version 2.2.5.
I think you need to gzip the body yourself and then paste it in. I could be wrong and if so would love this auto gzip feature!
A page at http://www4.example.com that tries to an xhr connection to http://www6.example.com/
The browser sends a GET request with this header:
Origin: http://www4.example.com
The www6.example.com server sends back:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://www4.example.com
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/plain
Date: ...
Keep-Alive: timeout=5, max=100
Transfer-Encoding: Identity
Server: Apache/2.2.20 (Ubuntu)
Vary: Accept-Encoding
X-Powered-By: PHP/5.3.6-13ubuntu3.7
And yet I get:
XMLHttpRequest cannot load http://www6.example.com/myscript.php?xhr=1&t=1234333223. Origin http://www4.example.com is not allowed by Access-Control-Allow-Origin.
My code matches my understanding of the CORS standard, and works fine with Chrome, Firefox, Opera, etc. so I'm going to assume this is a Safari 5.1 bug? My question is what do I need to do to work around it?
After a lot of trial and error, and watching network traffic, I think I can self-answer.
The Safari bug is that it sends an OPTIONS pre-flight request first, even though it is a GET request.
To add some extra complexity, it appears to only send this on the 2nd request. (I think this is because my 2nd request sends an extra custom header... but I couldn't actually isolate that, so I think there is something else going on as well - perhaps cache interactions?)
Sending Access-Control-Allow-Headers in the main response does not fix the problem: it does the OPTIONS request first, so never gets that far.
The fix I did was to put this at the very top of the PHP script:
if($_SERVER['REQUEST_METHOD'] == 'OPTIONS'){
header("Access-Control-Allow-Origin: ".#$_SERVER['HTTP_ORIGIN']);
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Allow-Headers: Last-Event-Id, Origin, X-Requested-With, Content-Type, Accept, Authorization");
exit;
}
Sending back "Access-Control-Allow-Headers: *" did not work. You have to explicitly list the headers you want. I briefly experimented and it appears they are case-insensitive.
Sending back "Access-Control-Allow-Methods: POST, GET, OPTIONS" was not needed.
As an aside, Cookies are sent, but basic auth details are not sent (despite explicitly listing the Authorization header there). This might be a deliberate limitation of the CORS implementation, as of this version of WebKit (534.57.2), not a bug.