Could not get any response when 204: No Content returned from server

[DCRichards]

1. Postman Version: 4.8.0 (4.8.0)
2. App (Chrome app or Mac app): Mac app
3. OS details: Mac OSX 10.11.5
4. Is the Interceptor on and enabled in the app: N/A (Mac app)
5. Did you encounter this recently, or has this bug always been there: Recent but not tried before
6. Expected behaviour: Status code should be 204 No Content and response headers displayed
7. Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app): No relevant info in the Dev tools, Postman Console shows Error: Parse Error in console, but with no further information.
8. Screenshots (if applicable)

Steps to reproduce the problem:

1. Make a request which returns a 204, in this case, I'm making a POST request.
2. Could not get any response displayed and the status code not shown as 204, instead just the message There was an error connecting to <URL>
3. Making the same request with 200, 201 etc response codes works correctly and the status code is correctly displayed. Trying the same request in cURL gives the correct response:

< HTTP/1.1 204 No Content
< Server: nginx/1.11.3
< Date: Tue, 18 Oct 2016 09:40:40 GMT

[DCRichards]

Just had a thought on this actually, could it be the Content-Type header? It looks like I might still be sending application/json as that's the default for the API and the way it's set up. Is Postman trying to parse it regardless of the 204?

[sdnts]

Which API are you using? Can you try doing the same using http://echo.getpostman.com/status/204? This is a test service.
I'm on v4.8, and this endpoint works fine for me, even with the Content-Type header.

[DCRichards]

@madebysid That works for me fine. The API is our own private API so sadly I can't open it up for poking, I might try when the response returns Content-Type: application/json rather than sending in the request

[sdnts]

@DCRichards Did you manage to reproduce this?

[DCRichards]

@madebysid I've not yet found an isolated test case. What I have seen is when proxying the same API call through a different server (so the 204 response is the same, but sent from my proxying server rather than the other), postman responds correctly, so it's something specific to that server. It's wordpress using the Oauth2 plugin but not sure why that's making a difference....

[sdnts]

@DCRichards This is just a thought, but do you perform a redirect in any way with your old setup? The app will, by default, try to follow these redirects. Can you try switching off automatic redirects in Settings > General and see if the problem persists?

[DCRichards]

Ah, that's a thought @madebysid, I'll give it a try and let you know! Thank you

[igorsantos07]

I'm facing the same issue, also on a private API :(

If I copy the curl code Postman generates, add -i to get headers, I get this on command-line:

HTTP/1.1 204 No Content:
Server: nginx
Date: Thu, 10 Nov 2016 17:52:12 GMT
Connection: keep-alive
Access-Control-Allow-Origin: https://localhost:8080

I was also outputting content-type: application/json, but removing it made no difference.

Linux Mint 18, Postman desktop 4.8.1. Nothing useful shows on the console, as with the OP.

[igorsantos07]

Actually, while testing out I removed the content-type while changed the timeout setting to a bad value.
Setting timeout to 0 (as default) and not sending the JSON content-type with the 204 response solved the matter for me.

I found no clear, canonical answer on 204 vs. Content-Type, but from my humble interpretation, 204 should ideally not send a Content-Type header, as there's no content to encode neither would be (as in the case of a HEAD response):

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

Thus, it feels that Postman is correct on trying to parse something that has a content-type. Maybe a warning should be added to that list of suggestions, stating that empty responses should not contain a content-type? Or should it be a cool guy and skip parsing if the response is empty?

[chimit]

The problem is still there. Postman has a confusing behavior on 204: No Content server response. It doesn't show the response body and even HTTP status. It only displays an error:

Could not get any response
There was an error connecting to http://local.app/v1/devices/2.
Why this might have happened:
The server couldn't send a response:
Ensure that the backend is working properly
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
Client certificates are required for this server:
Fix this by adding client certificates in Settings > Certificates
Request timeout:
Change request timeout in Settings > General

Please, make Postman able to display at least HTTP response status 204 or better along with a response body.

[malvadeza]

Some problem here.
On Desktop App (Windows/Mac) it doesn't work, but as the Chrome App postman is able to show the response code (it works).

[themirror178]

Same problem here (Windows App), works on Chrome App.

[Whyounes]

Problem still exists in version 5.1.2

[0xceb1d]

Still having this issue.
Postman displays the body when changing response to something else (i.e 200)

[developer99]

I do not think it is supposed to return anything by standards.

See https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

Oh. duh @igorsantos07 already said this. :)

[developer99]

In my case, perhaps I have misinterpreted the reason to return 204. I am using it when a query seeking records does not find any. No records, return 204 (no content).

The server has fulfilled the request but does not need to return an entity-body

But perhaps I DO need to return data and should return status 200 OK and return a message such as "message":"No records found" and/or an empty record set.

Which would be best for the developer? Status 204 (No content) or Status 200 (OK) with empty record set and/or message?

I do not think either breaks any rules or interpretation of status codes necessarily.

[igorsantos07]

@developer99 I suggest you to post those questions on a forum such as StackOverflow. That's off-topic, as we're discussing here an issue with Postman interpretation of 204 responses :)

(psssst, hint: return 200 {} instead of a message stating there are no records. Your API should return a list of records, even when that list is empty)

[ghost]

I've the same issue in macOS native app and chrome app. But if the service was called from localhost everything work fine.

[nirmalgoswami]

same issue here

[ERPedersen]

I can confirm that this is happening for me and another of my colleagues as well. It happens regardless of whether the request has a body or not.

[kapitanluffy]

I am having this issue as well.

[jmauerhan]

This is a problem for me as well, if I do this request in curl, I get the correct response:

HTTP/1.1 204 No Content
Server: nginx
Content-Type: application/json
Connection: keep-alive
Cache-Control: no-cache, private
Date: Tue, 15 May 2018 21:43:08 GMT

But Postman shows me the confusing "Could not get any response" and no way to view the headers to see that I did in fact get a 204.

[omar-faruk-sust]

I am having same issue as well. anyone have any solution ?

[yanxiaodi]

I think it's not the problem of Postman. As @igorsantos07 said, we should follow the HTTP specification. Make sure there is no body in the response if it returns 204. Otherwise, ask the APIs service provider first.

[kudlohlavec]

Totally agree with @igorsantos07 and @yanxiaodi . I had the same issue, I was testing some stuff so I got some testing messages in the code and were returning 204 response with notorious "Could not get any response" message in postman.
After removal of all messages in the code and returning only empty 204 response code, everything started to work properly in postman.

[shamasis]

Hey... I took a dig at locally reproducing this. Phew! Getting a server to misbehave is really tricky. I am very comfortable with NodeJS and sadly I could not create a server that would send 204 and body.

I am sure of one thing though - can confirm that 204 without body works fine on Postman, irrespective of request method / header / whatever.

I will switch to some low-level language to make a misbehaving server. PS If anyone has anything handy to speed me up, let me know.

The test code I used (not relevant):

const http = require('http')
const port = 3000

const requestHandler = (request, response) => {
  console.log(request.url)
  response.writeHead(204);

  response.write('some data', function () {
    console.log('sent');
    
    response.end('Hello Node.js Server!');
    console.log('end');
  });
}

const server = http.createServer(requestHandler)

server.listen(port, (err) => {
  if (err) {
    return console.log('something bad happened', err)
  }
  console.log(`server is listening on ${port}`)
})

[filipecatraia]

I found a number of related issues:

• http: HPE_INVALID_CONSTANT parse error if CONNECT response contains body nodejs/node-v0.x-archive#7019
• HPE_INVALID_CONSTANT: Add error hint that it might be TCP or other non-HTTP endpoint request/request#1713
• https://stackoverflow.com/questions/34769824/what-does-this-error-mean-hpe-invalid-constant/42346053
• HTTP2 server + HTTP request -> ParseError: HPE_INVALID_CONSTANT nodejs/node#21000
• HPE_INVALID_CONSTANT Errors with HTTP/TCP nodejs/node-v0.x-archive#4863

And so on. They seem to be related to @shamasis finding. At work we couldn't process any response from Symphony, as node choked on the following:

$response = new JsonResponse();
$response->setStatusCode(JsonResponse::HTTP_NO_CONTENT);
return $response

Changing that to:

$response = new Response();
$response->setStatusCode(Response::HTTP_NO_CONTENT);
return $response

makes the problem go away. JsonResponse always came back with an actual content length of 2, regardless of the Content-Length header being present or not. Node would never parse the request. Now it's a proper empty response so it works.

Does this help?

[HeroicOvenmitt]

I had a silly issue causing this same problem for a little while. For me I was returning a 204 with 'Success' set to false. -_-

[p00j4]

I too ran into this and after hours of hitting the walls, here is what now hopefully can save someone's time:

Background We were using python app and one day, we added a reverse proxy in our nginx conf proxy_pass and then started noticing the same calls started responding slower. Initially we were blindly checking the conf and postman, curl stuff and finally figured the pattern that it's only happening for 204 response codes. Since the same call if was hit using cURL, we were immediately getting the response hence we thought, it's a bug at postman level or something to do with nginx and postman together.

Towards finding the fix:

1. On requesting, without nginx: ran cURL with -v this time,
found that the server sends "assume close after body" also notice the content length.

2. On requesting using nginx's reverse proxy:
the reponse disn't have any instruction to close and observe th last line "connection left intact", also notice the content length.

This difference was enough to confirm it's nginx config which needs a fix and found that keepalive_timeout 0; came as the life savior hack, i.e. after reloading nginx, now postman knows that connection is closed, there is no need to wait more for 204 case.
And more reading revealed that the default keepalive_timeout is 60 seconds hence postman was receiving the signal to close connection and return after a minute (yes I had calculated the time it was taking to return from postman to report the issue to team postman, because the cURL copied from the same postman was returning immidately 🤦‍♀️)

For reference, Nginx conf looks like this:

location /my_route/ {
         proxy_pass  <my_domain>:<my_port>/;
         proxy_http_version  1.1;
         keepalive_timeout 0;
   }

I'm still new to nginx and proxies, learned new lessons of API redirection rules against refusing to change from 204 to 200 without understanding the actual reason 😄

[eysikal]

I ran into this same issue today and it cost me a few hours thinking it was my code that was the issue.

I encountered the issue when trying to set up Lavavel Sanctum and hitting the /sanctum/csrf-cookie route, which returns a 204 with no content and 2 cookies.

macOS 10.15.4 running Laravel Valet.

[Niush]

@eysikal Did you find any suitable solution for this? Postman seems to just throw Error: Parse Error: Expected HTTP/ and also ignore the cookie so user is not authenticated.

[eysikal]

@Niush No, I never did. I ended up using Chrome extension tool to test my API and that’s when I discovered that it was Postman that had the issue.

[mccannt]

@eysikal We have made some recent changes to resolve this.

What version of our application are you using currently?
Do you see this issue with any other endpoint that returns a 204?

[Niush]

@mccannt After latest update (Windows Version 7.31.1) it is working from Build View just fine.
But, still not working in Pre-requests Script.
While using sendRequest as below:

pm.sendRequest({
    url: pm.environment.get('base_web_url')+'/sanctum/csrf-cookie',
    method: 'GET',
}, function (error, response, {cookies}) {
    // THROWS ERROR: TypeError: Cannot destructure property 'cookies' of 'undefined' as it is undefined.
})

And console.log of response has 0 cookie and 0 header. (Although, it does exist as it works from Build view)

I also tested with https://httpstat.us/204 endpoint, and it works fine. So, it is might be with the way Laravel Sanctum returns the response.

[mccannt]

Thanks for the follow-up @Niush I agree that this does sound like an isolated issue with Laravel Sanctum as this appears to work as expected when hitting other valid endpoints that return a 204.

Closing this issue for the time being. If this is still an issue against endpoints other than Laravel Sanctum, please feel free to reopen with details on how to replicate this.

[nmfzone]

@eysikal Now, you need to pass Accept header as application/json to avoid this issue in Laravel Sanctum 2.9.0.

pm.sendRequest({
    url: `${pm.variables.get('host')}/sanctum/csrf-cookie`,
    method: 'GET',
    header: {
        'Accept': 'application/json'
    }
}, function (error, response, { cookies }) {
    if (!error) {
        pm.environment.set('xsrf-token', cookies.get('XSRF-TOKEN'))
    }
})

[rushi7997]

@nmfzone Thanks for this comment it was really helpful.