Why Your Mobile App Can Time Out on Responses With an Empty Body
While testing an Android app, one of our QA engineers noticed something odd: after stripping the response body from a request using a MITM proxy, the app didn’t just return an empty result. Instead, it kept waiting… and waiting… until finally throwing a timeout error. On the UI, the loader animation spun endlessly before failing.
At first glance, this looks like a bug. After all, the server sent back a 200 OK; shouldn’t the app consider that a valid response? The answer lies deep in how HTTP/1.1 handles response bodies.
The Core Issue
The problem is not that the app ignores the HTTP status code, but that it expects not only a response header, but also a properly defined body.
\ When the server says “I’ll send you a body”, the client (your app) trusts that promise. If the body never arrives, the client keeps waiting until a timeout occurs.
Why It Happens
1. Transfer-Encoding: chunked
\ In the failing case, the response contained this header: Transfer-Encoding: chunked
\ This header tells the client: “Don’t worry about the total size, I’ll send the body in chunks.”
\ Per RFC 7230:
\ Since the server promised chunks but sent none, the client keeps waiting for data that will never come. Eventually, it times out.
2. Missing Content-Length
If the server did not use Transfer-Encoding, the next expectation would be an explicit Content-Length.
\ RFC 7230 (HTTP/1.1) Content-Length
\ For a truly empty body, the correct header would be: Content-Length: 0
\ Without it, the client cannot know for sure that the body is absent.
Why the Example Was Wrong
In our test setup, the response was stripped incorrectly. To signal a deliberately empty body in compliance with HTTP/1.1, the response must:
- Not include
Transfer-Encoding: chunked - Include
Content-Length: 0
\ Only then will the client immediately understand: “Nobody is coming, I can stop waiting.”
How to Reproduce the Correct Case in Charles Proxy
If you want to simulate this behavior correctly, here’s how to configure Charles Proxy:
\ On the request:
- Replace the
Accept-Encodingheader withIdentity. This disables compression (otherwise you’ll hit SSL errors).
\ On the response:
- Remove the body entirely
- Add
Content-Length: 0 - Remove the
Transfer-Encodingheader
\ Now, your app will immediately recognize the empty response and behave accordingly.
Takeaways
- HTTP responses with
Transfer-Encoding: chunkedimply that a body is coming. - If the body is missing, clients will wait until a timeout.
- To signal a truly empty response, use
Content-Length: 0and dropTransfer-Encoding. - When testing with tools like Charles Proxy, make sure you’re simulating the protocol correctly, not just stripping content.
👉 This little quirk reminds us how much apps rely on strict adherence to HTTP standards. A missing or misconfigured header can completely change how the client interprets the response.
You May Also Like
VIRTUAL Weekly Analysis Jan 21
Dogecoin, Shiba Inu & XYZVerse: Three Meme Coin Paths — Stability, Gradual Growth & Explosive Upside?
