Parse error when no HTTP/ ... in the response message

[SamuelH91]

When server is sending response which doesn't have HTTP/1.1 .... in the beginning of the message Postman Desktop app gives an error "Parse Error: The server returned a malformed response". Below error message from console.

"POST http://192.168.225.1/ Error: Parse Error: Expected HTTP/ Request Headers Content-Type: application/json User-Agent: PostmanRuntime/7.26.5 Accept: / Host: 192.168.225.1 Request Body"

Response was otherwise only json. It is visible in Postman Chrome wihtout any errors.

[DannyDainton]

Hey @SamuelH91

Are you able to provide us with an endpoint the full request that shows the issue as it's going to be difficult to reproduce the problem with that IP.

Which version of the app are you using?

[SamuelH91]

• Newest desktop application on Windows.

Normally server should start it's response with something like this

HTTP/1.1 200 OK Date: < some date > Content-Type: application/json Content-Length: < actual size >

{"example":"data"}

This particular server skipped the beginning and went right to the json. Old Postman Chrome doesn't raise Parse Error like Postman Desktop version. Of course, I am able to see the response in Wireshark, but it isn't quite practical.

[DannyDainton]

Is this an endpoint that you control or have control over?

Could you send the curl command for that request so that we can at least import it and see what it looks like.

[SamuelH91]

Not at the moment, but it isn't necessary at all. It easily replicated by sending the reply to any rest request (from Postman) from any server that doesn't include Http/1.1 .... + Headers to its response. The response ONLY includes json. Then you are able to see the Parse Error.

[DannyDainton]

Can you give us an example of one that you have seen this happening with please?

Being able to replicate what you can see in front of you is vital to be able to investigate this more.

[SamuelH91]

I can probably code some extra simple server tomorrow if you are not able to replicate it before.

[DannyDainton]

Can you share a screen shot of what you're seeing and the error that you can see in Postman.

[SamuelH91]

Here is a simple python test server:

simpleTestServer.zip

Run it (listens on 80 port) python simpleTestServer.py Make any rest requests from Postman to localhost: -> Every other message from server to any request from postman gives parse error. (Starting from error)

[SamuelH91]

Example:

No response body visible when Parse Error

[SamuelH91]

From old Postman chrome plugin (HTTP/1.1 ... not included in response) (No Parse Error):

vs (HTTP/1.1 included in response)

[Cediddi]

I'm also having a very similar exception on postman when a HEAD request returns any content-length != 0 (which RFC says HEAD should return content-length same to what it would've been in if it was a GET)

I double checked with curl, same endpoint, same request, only difference is content-length being 0 and not.

[natenho]

I'm getting the same error, simulating an empty request situation:

Parse Error: The server returned a malformed response

Error: Parse Error: Expected HTTP/

Here are the full payloads captured using Wireshark:

POST /wsRecarga.asmx/NotificarPagamentoProcessado HTTP/1.1
Content-Type: application/json
User-Agent: PostmanRuntime/7.26.10
Accept: */*
Cache-Control: no-cache
Postman-Token: daa04e18-8e75-430e-b039-1b29deeec4a9
Host: localhost:9080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 0

HTTP/1.1 400 Bad Request
Cache-Control: private, max-age=0
Content-Length: 75
Content-Type: application/json
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcQ29kZVxiaXRidWNrZXRcdml2by13c3JlY2FyZ2Fcd3NSZWNhcmdhXHdzUmVjYXJnYS5hc214XE5vdGlmaWNhclBhZ2FtZW50b1Byb2Nlc3NhZG8=?=
X-Powered-By: ASP.NET
Date: Fri, 26 Feb 2021 18:55:56 GMT

{"resultCode":"err","failureReason":"P0013","message":"Empty request body"}{"d":null}

I think Postman should be able to parse the response or at least showing the raw response content, as it does for other situations.

The same request via curl works as expected.

[godspeed20]

i have the same error, but in my case it's because the server is configured as http/2, and i think (?) postman doesn't support that? at least from searching around it looks like that might be the case. Anyway might not help but thought i'd add here as it's the exact same response that I see when trying to query a get on http/2 service

[al-amin-chayan]

I've spend a hole day to figure out the issue but failed to resolved. It's not working for localhost, but for remote endpoint it works.

below is the console output:

[marufmax]

+1 having the same issue. is there any plan for fix this? seems like sometimes can't even use the Postman because of this

[Eyad-Bereh]

In case this might be helpful for someone: I've been having this problem also on my local endpoint, i was sending HTTP status code 204 (No Content), i replaced it with 200 (OK) and everything worked fine I actually find this to be a strange issue, any explanations would be appreciated

[enbis]

In my case, specify the status code fixed the problem. I had the same Parsing Error on Postman interface so I decided to do some tests using curl and I received the curl: (1) Received HTTP/0.9 when not allowed error. Then, forcing the proper status_code in the response header everything went smoothly.

[iforwms]

Also experiencing the same issue when the server returns a 204 empty response.

[lechediaz]

I had the same problem today, but I resolved it setting the header Content-Length properly in my http response

[lydengit]

I solved it by setting the writeHead eg: response.writeHead(statusCode)
OR response.writeHead(statusCode, {'Content-Type': 'application/json'})

[alex-scott]

Seems we are affected by same issue.

I am testing a local PHP/Apache website. it works fine for years we are developing, from command line and from API. Now tryting to use PostMan, and get the following in the PostMan console:

GET http://tester2.local/api-v2/login

Error: Parse Error: Expected HTTP/

Request Headers
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Postman-Token: 1e8bfce2-e10a-42c6-8b7e-5fcc25d81ade
Host: tester2.local
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: PHPSESSID=f06cde50cb3bc3a0cc95650df21b3738

When I am testing with curl, it works just fine and gives correct HTTP headers:

curl -v http://tester2.local/api-v2/login
*   Trying 10.10.10.1:80...
* TCP_NODELAY set
* Connected to tester2.local (10.10.10.1) port 80 (#0)
> GET /api-v2/login HTTP/1.1
> Host: tester2.local
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 25 Nov 2021 14:24:39 GMT
< X-Powered-By: PHP/7.4.13
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< cache-control: no-store, no-cache, must-revalidate, max-age=0
< content-security-policy: frame-ancestors 'self'
< Access-Control-Allow-Origin: http://localhost:5000
< Access-Control-Allow-Headers: X-Requested-With, Content-Type, Accept, Origin, Authorization, Set-Cookie
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Set-Cookie: PHPSESSID=ec28d265294aeda1817f0d1695b82393; path=/; domain=.tester2.local; HttpOnly
< Content-Length: 11
< Content-Type: application/json
< 
* Excess found in a read: excess = 27, size = 11, maxdownload = 11, bytecount = 0
* Connection #0 to host tester2.local left intact
{"ok":true}

[joseluisq]

The same here. I'm trying this small php script under nginx which works fine via curl or hoppscotch but fails with postman.

$ curl -vX POST http://localhost:8088/home/xyz/abc124
*   Trying 127.0.0.1:8088...
* Connected to localhost (127.0.0.1) port 8088 (#0)
> POST /home/xyz/abc124 HTTP/1.1
> Host: localhost:8088
> User-Agent: curl/7.80.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Host: localhost:8088
< Date: Sun, 26 Dec 2021 22:04:06 GMT
< Connection: close
< x-header-one: Header Value 1
< x-header-two: Header Value 2
< content-type: application/json
< content-length: 23
< 
* Closing connection 0
{"some_data":223424234}

[joseluisq]

The same here. I'm trying this small php script under nginx which works fine via curl or hoppscotch but fails with postman.

$ curl -vX POST http://localhost:8088/home/xyz/abc124
*   Trying 127.0.0.1:8088...
* Connected to localhost (127.0.0.1) port 8088 (#0)
> POST /home/xyz/abc124 HTTP/1.1
> Host: localhost:8088
> User-Agent: curl/7.80.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Host: localhost:8088
< Date: Sun, 26 Dec 2021 22:04:06 GMT
< Connection: close
< x-header-one: Header Value 1
< x-header-two: Header Value 2
< content-type: application/json
< content-length: 23
< 
* Closing connection 0
{"some_data":223424234}

Correcting my previous comment. I was using a dev server and an old postman version. However if I use a latest postman like 9.6.1 as well as a proper server like Nignx my requests work with no this postman issue.

[shutuper]

Bug, when trying to send connection request to socket.io server through postman(last version on desktop the same):

---

logs:

---

[13194][1645654722816][main][error]["Postman Agent~Main~UncaughtException",{"name":"TypeError","message":"object null is not iterable (cannot read property Symbol(Symbol.iterator))","stack":"TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))\n at Socket.<anonymous> (/Applications/Postman Agent.app/Contents/Resources/app.asar/lib/common/services/SocketIOClient.js:190:15)\n at Object.onceWrapper (events.js:422:26)\n at Socket.emit (events.js:327:22)\n at addChunk (internal/streams/readable.js:309:12)\n at readableAddChunk (internal/streams/readable.js:284:9)\n at Socket.Readable.push (internal/streams/readable.js:223:10)\n at TCP.onStreamRead (internal/stream_base_commons.js:188:23)"}]

---

(desktop clients shuts after this error)

Responce:

---

Could not connect to http://localhost:8080/admin 00:23:13 Error: Parse Error: Expected HTTP/ Handshake Details Request URL: http://localhost:8080/api/v1/private/ws/?EIO=4&transport=websocket Request Method: GET Request Headers Sec-WebSocket-Version: 13 Sec-WebSocket-Key: qKBpW+sPUeQko22j38d6gw== Connection: Upgrade Upgrade: websocket Authorization: auth Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Host: localhost:8080

---

Pls fix)))

[nickhoeferpickpro]

I have the same issue

[lptarik]

Same issue here

[ale-lit]

Same issue here

When adding a this header to a server response: header('Content-Length: ' . strlen($fileContent)); - error in Postman Without this header and when opened in a browser - everything is ok

[shubhbhargav]

@ale-lit @lptarik @nickhoeferpickpro Can you please share the CURL output of these requests? This issue generally pops up for customized HTTP responses (including headers) which do not follow corresponding RFCs.

[ale-lit]

@shubhbhargav hi!

After updating postman the problem seems to be gone 👍

[shubhbhargav]

Thanks for the confirmation @ale-lit . We will wait for a few weeks to see if anyone else is facing this issue anymore. If not, we will close it. :)

[mwcgit]

I encountered this bug today as of 11/2/2022

[shubhbhargav]

@mwcgit Can you share the CURL output for it? Looks like an issue where the HTTP response doesn't contain the protocol definition at the top.

[mwcgit]

@shubhbhargav,

curl --location --request POST 'http://localhost:3001/password-reset' \
--header 'Content-Type: application/json' \
--data-raw '{
    "reset-password": {
        "email": ""
    }
}' 

[shubhbhargav]

@mwcgit Can you add -i in the CURL request and re-share the output once please? It will give the entire response in raw format. That will be helpful to see what exactly is causing the parsing error.

[nostis]

For me that was problem with wrong Content-Length header value. After fixing bug in which response body was wrongly counted everything works. (In my case I had CSV download type response and I didn't count table header names)

[brandyodhiambo]

This problem arises due to wrong port number check your database port number and change it on your postman .I had the same problem but when i change the port number to the correct one it worked well

[dethmetaljeff]

For me that was problem with wrong Content-Length header value. After fixing bug in which response body was wrongly counted everything works. (In my case I had CSV download type response and I didn't count table header names)

Same issue w/ me, the server is replying with an incorrect content-length header value. I have no control over the server, so, ideally we'd have a way to do what curl is doing and just keep reading until we get the whole response?

Here's my curl output:

  * Connected to 10.241.66.4 (10.241.66.4) port 443 (#0)
  * ALPN: offers h2
  * ALPN: offers http/1.1
  * (304) (OUT), TLS handshake, Client hello (1):
  * (304) (IN), TLS handshake, Server hello (2):
  * TLSv1.2 (IN), TLS handshake, Certificate (11):
  * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  * TLSv1.2 (IN), TLS handshake, Server finished (14):
  * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (OUT), TLS handshake, Finished (20):
  * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (IN), TLS handshake, Finished (20):
  * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  * ALPN: server did not agree on a protocol. Uses default.
  * Server certificate:
  *  subject: C=US; ST=California; L=San Jose; O=Super Micro Computer; OU=Software; CN=IPMI
  *  start date: Feb 25 00:00:00 2022 GMT
  *  expire date: Feb 25 00:00:00 2025 GMT
  *  issuer: C=US; ST=California; L=San Jose; O=Super Micro Computer; OU=Software; CN=IPMI
  *  SSL certificate verify result: self signed certificate (18), continuing anyway.
  > PATCH /redfish/v1/Managers/1/NetworkProtocol HTTP/1.1
  > Host: 10.241.66.4
  > User-Agent: curl/7.86.0
  > Accept: */*
  > Authorization: Basic XXXXXXX
  > Content-Type: application/json
  > Content-Length: 163
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < Content-Length: 86
  < OData-Version: 4.0
  < OData-Version: 4.0
  < Content-Type: application/json; charset=utf-8
  < Strict-Transport-Security: max-age=31536000; includeSubdomains
  < X-XSS-Protection: 1; mode=block
  < Content-Security-Policy: default-src 'self';connect-src 'self' ws: wss:;frame-src 'self' data:;img-src 'self' data:;object-src 'self';font-src 'self' data:;script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline';worker-src 'self' blob:;
  < X-Frame-Options: SAMEORIGIN
  < X-Content-Type-Options: nosniff
  < Date: Fri, 17 Mar 2023 09:55:40 GMT
  <
  * Excess found in a read: excess = 202, size = 86, maxdownload = 86, bytecount = 0
  * Closing connection 0
  * TLSv1.2 (OUT), TLS alert, close notify (256):
  {"Success":{"code":"Base.v1_4_0.Success","Message":"Successfully Completed Request."}}%

[sitistas]

Something that worked in my case, was to enable strict HTTP parser. In the application that I am working on, the client needs to receive the code "204" on success of the PUT request. Normally, this sends no content as a response, but enabling the option of the strict HTTP parser, seemed to work for me.

[newinternetboy]

i used wrong server port, when i corrected it, it`s work

[ilyvion]

I'm experiencing this when returning a 304 response from my server.

❯ curl -i -H "If-None-Match: RA_kwDOAzCBa84Hec-5" http://localhost:3000/releases/qc-ext.latest.meta.js
HTTP/1.1 304 Not Modified
etag: RA_kwDOAzCBa84Hec-5
date: Tue, 12 Sep 2023 08:24:27 GMT

❯ curl --verbose -H "If-None-Match: RA_kwDOAzCBa84Hec-5" http://localhost:3000/releases/qc-ext.latest.meta.js
*   Trying 127.0.0.1:3000...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET /releases/qc-ext.latest.meta.js HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/8.0.1
> Accept: */*
> If-None-Match: RA_kwDOAzCBa84Hec-5
>
< HTTP/1.1 304 Not Modified
< etag: RA_kwDOAzCBa84Hec-5
< date: Tue, 12 Sep 2023 08:27:14 GMT
<
* Connection #0 to host localhost left intact

❯

Postman says "Error: Parse Error: Expected HTTP/" on the same request

[roommate6]

In case this might be helpful for someone: I've been having this problem also on my local endpoint, i was sending HTTP status code 204 (No Content), i replaced it with 200 (OK) and everything worked fine I actually find this to be a strange issue, any explanations would be appreciated

I had a response with status code 100 on my post end point. (the only one that does not work). And, after changed it to 400, it fixed the issue. Idk why. Some explanation?

[Eyad-Bereh]

I had a response with status code 100 on my post end point. (the only one that does not work). And, after changed it to 400, it fixed the issue. Idk why. Some explanation?

@roommate6 Well, after about 3 years I concluded that maybe it's fine to work that way because 204 means no content. However, the behavior of postman is strange, and it shouldn't be treated as an error.

I'm on the latest version and this problem doesn't exist here. Have you tried a newer version?

[roommate6]

@Eyad-Mohammed-Osama I gived up on responding with the status code 100. I am making an API unsing ASP.NET. I have a controller with 4 end points. 3 of them are working just fine. The POST end point that returns a status code 100, when the client tries to add a new object, when we have reached the limit of objects (0 or 1 objects can exist in the database, like a singleton collection) gives the parse error/malformed format/etc in swagger and post man. I didn't tried newer versions. But swagger gives an error as well. I am responding with status code 400... and it works just fine.

[Fabio-JoinTech]

for me this worked well

http_response_code(204); exit();