I'm attempting to debug an issue where a iPhone client throws an error that seems to indicate the http response was not received when hitting my API. When comparing traffic of the bad case to the good ones I notice that even in the cases where this works for other clients my wireshark does not have an HTTP response listed for the call in question and the request contains no "Response in Frame:" link. If I use the follow TCP stream I see the response. If I dig through the TCP entries I see a reassembled PDU with the HTTP 201 response and the appropriate JSON payload. But there is no HTTP capture entry showing the response. Again, this is a case in which the client was able to receive and process the response, but I wonder if it's pointing to some anomaly that could help explain the issue I'm seeing.
When I look at the logs from the failed test from the iPhone, the HTTP request entry contains a "Response in frame" link to an HTTP 204 No Content, which is not the correct response but is rather a response from a previous HTTP call in the same stream. This is reinforced by follow TCP stream feature which again properly shows the appropriate HTTP 201 response with the correct payload.
So my questions are these: 1) Is it normal for Wireshark to not log an HTTP response that was clearly sent? 2) Is it normal for Wireshark to misidentify the HTTP response in the "Reponse in frame" link? 3) Are these likely symptoms of my problem or simply artifacts of how http or wireshark works?
asked 30 Jan '15, 11:31