Postman shows "Could not get any response" even though response is OK - wcf

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.

Related

Sending post request to API with multipart content-type

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.

Edge browser appears to discard response payload

I have a web app that returns a PDF to the browser, which works fine in Chrome and Firefox, however it does not work in Edge (version 38.14393.0.0). The response header looks like this:
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Origin: *
Cache-Control: no-store, no-cache, must-revalidate
Content-Disposition: inline; filename="Invoice.PDF"
Content-Length: 9255
Content-Type: application/pdf
Date: Mon, 30 Jan 2017 04:38:25 GMT
Pragma: no-cache
Server: Microsoft-IIS/10.0
I've seen other questions suggesting that 2 requests are sent from Edge, one of which should be ignored, but in my case there is only one, and it appears that the payload is being ignored because Edge reports:
This resource has no response payload data
..which is in the Response Body section for the request in the Network analyzer in Developer Tools. Using attachment instead of inline also does not work, and I wouldn't expect it to if Edge thinks there's no content in the response.
Any clues?
Edit: When the Content-Type is changed to: text/plain, the response body is no longer being discarded (but does not solve the problem), so I assume it's something specific to application/pdf

In my case, it appears the payload data is being discarded because I was attempting to use createObjectURL on the result. This post:
Setting window.location or window.open in AngularJS gives "access is denied" in IE 11
Has a solution that kind of works: Edge still does not actually open the PDF like other browsers are capable of, however it gives the user the option to save it.

Cannot generate an authorization code on API Explorer

I'm trying to collect and download my lifelog user data. The first step into doing this is getting a user-access token. I am encountering problems while requesting authorization.
From the sony developer authenticization page I am told to input the following code into my API explorer:
https://platform.lifelog.sonymobile.com/oauth/2/authorize?client_id=YOUR_CLIENT_ID&scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read
I am supposed to receive the authorization code as such:
https://YOUR_CALLBACK_URL?code=abcdef
However, this is what the current situation is actually like:
I have replaced my actual client ID below with MY_CLIENT_ID for security reasons
INPUT:
GET /oauth/2/authorize?client_id=MY_CLIENT_ID&scope=lifelog.profile.read%2Blifelog.activities.read%2Blifelog.locations.read HTTP/1.1
Authorization:
Bearer kN2Kj5BThn5ZvBnAAPM-8JU0TlU
Host:
platform.lifelog.sonymobile.com
X-Target-URI:
https://platform.lifelog.sonymobile.com
Connection:
Keep-Alive
RESPONSE:
HTTP/1.1 302 Found
Content-Length:
196
Location:
https://auth.lifelog.sonymobile.com/oauth/2/authorize?scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read&client_id=MY_CLIENT_ID
Access-Control-Max-Age:
3628800
X-Amz-Cf-Id:
HILH9w3eOm-6ebs_74ghegYQyWS4xyqA1l0gXPRJuuubsoZ6eiiS3g==
Access-Control-Allow-Methods:
GET, PUT, POST, DELETE
X-Request-Id:
76caccfc976d40259ef30415d10980e9
Connection:
keep-alive
Server:
Apigee Router
X-Cache:
Miss from cloudfront
X-Powered-By:
Express
Access-Control-Allow-Headers:
origin, x-requested-with, accept
Date:
Sun, 22 Jan 2017 03:00:42 GMT
Access-Control-Allow-Origin:
*
Vary:
Accept
Via:
1.1 dc698cd00b7ec82887573cfaba9ecca6.cloudfront.net (CloudFront)
Content-Type:
text/plain; charset=utf-8
Found. Redirecting to https://auth.lifelog.sonymobile.com/oauth/2/authorize?scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read&client_id=MY_CLIENT_ID
Nowhere can I see the authorization code in the above code. I even tried copying and pasting the URL (on the last line) into my browser, it says "localhost.com took too long to respond"
This is where I input my request
I am not sure whether it is an issue with the callback URL. I don't have an actual website or app made, I just used the default localhost
I am a beginner in this and would really appreciate all help.

Problems attaching a file to a task via API with Active Collab v5

We are using the API of Active Collab v5, which works quite good.
Unfortunately, we are not able to attach a successfully uploaded file to an existing task. We tried several different ways, but never suceeded.
The one way we believe should work, is shown here:
PUT https://<DOMAIN>/api/v1/projects/<PROJECTID>/tasks/<TASKID>
Accept: */*
X-Angie-AuthApiToken: <TOKEN>
Content-Type: text/plain
Accept-Language: en-us
Accept-Encoding: gzip, deflate
{
"attach_uploaded_files": [
"<CODE>"
]
}
Content-Type: application/json; charset=utf-8
X-Angie-ApplicationVersion: 5.11.23
Pragma: no-cache
Server: Apache
Content-Encoding: gzip
Vary: Accept-Encoding
{"single":{"id":<TASKID>,"class":"Task","url_path":"\/projects\/<PROJECTID>\/ tasks\/
<TASKID>","name":"<TASKNAME>","assignee_id":0,"delegated_by_id":0,
" completed_on":null,"completed_by_id":null,"is_completed":false,"comments_count": 0,
"attachments":[],"labels":[],"is_trashed":false,"trashed_on":null," trashed_by_id":0,
"project_id":<PROJECTID>,"is_hidden_from_clients":false,"body":"<BODYTEXT >",
"body_formatted":"<BODYTEXT>","created_on":1481044542,"created_by_id":20,
" updated_on":1481052449,"updated_by_id":20,"task_number":258,"task_list_id":<TLID> ,
"position":17,"is_important":false,"start_on":null,"due_on":null,"estimate":0,
" job_type_id":0,"total_subtasks":0,"completed_subtasks":0,"open_subtasks":0,
" created_from_recurring_task_id":0},"subscribers":[20],"comments":[],"reminders": [],
"subtasks":[],"task_list":{"id":<TLID>,"class":"TaskList",
"url_path":"\/ projects\/<PROJECTID>\/task-lists\/<TLID>","name":"Inbox",
"is_trashed":false,"trashed_on": null,"trashed_by_id":0,"completed_on":null,
"completed_by_id":null,"is_completed" :false,"project_id":8,"created_on":1480605343,
"created_by_id":20,"updated_on": 1481052420,"updated_by_id":20,"start_on":null,
"due_on":null,"position":1," open_tasks":1,"completed_tasks":44},"tracked_time":0,
"tracked_expenses":0}
We always get a 200 OK, but the file remains unattached.
Can someone please tell us what we are doing wrong?
Thank you for your support and best regards.
Lukas.

Everything looks fine except the "Content-Type" header of your request.
Since you are sending a JSON encoded body to the API you need to set the request header to
"Content-type: application/json; charset=utf-8".
cheers
Nick

Is it possible to send GZip'd HTTP POST request by using PAW

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!