Meaning of differences between responses in WireShark - 2 web servers

Question

This question relates more to HTTP and web server responses than to WireShark, yet I am hoping that someone with intimate knowledge of comms and HTTP in particular, could take a look at the following and possibly offer insights.

I have a device which issues GET and POST requests to a web endpoint.

When the device issues these requests to an Apache web server, it responds properly to the Apache web server HTTP/1.1 200 OK responses.

The WireShark capture appears as follows:

Frame 28: 96 bytes on wire (768 bits), 96 bytes captured (768 bits)
Ethernet II, Src: ...
Internet Protocol Version 4, Src: ...
Transmission Control Protocol, Src Port: http (80), Dst Port: nsstp (1036), Seq: 144, Ack: 257, Len: 30
[2 Reassembled TCP Segments (173 bytes): #27(143), #28(30)]
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [Message: HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.1
        Status Code: 200
        Response Phrase: OK
    Content-Length: 30\r\n
        [Content length: 30]
    Content-Type: text/plain\r\n
    Date: Mon, 10 Sep 2012 13:15:16 GMT\r\n
    Server: CherryPy/3.1.0beta3 WSGI Server\r\n
    \r\n
Line-based text data: text/plain

When the device issues these requests to an Microsoft-HTTPAPI/2.0 endpoint, it does not respond to the HTTP/1.1 200 OK responses.

The WireShark capture appears as follows:

Frame 49: 240 bytes on wire (1920 bits), 240 bytes captured (1920 bits)
Ethernet II, Src: ...
Internet Protocol Version 4, Src: ...
Transmission Control Protocol, Src Port: http (80), Dst Port: kyoceranetdev (1063), Seq: 1, Ack: 257, Len: 174
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [Message: HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.1
        Status Code: 200
        Response Phrase: OK
    Keep-Alive: true\r\n
    Content-Length: 0\r\n
        [Content length: 0]
    Content-Type: text/plain\r\n
    Server: Microsoft-HTTPAPI/2.0\r\n
    Date: Mon, 10 Sep 2012 13:29:20 GMT\r\n
    Connection: keep-alive\r\n
    \r\n

I will really appreciate any assistance which may shed light on the possible cause.

Answer 1

0

Well, this is not only not so much an HTTP question as it is a Wireshark question, it is more of an application specific question. Both responses are valid HTTP, but they do have different behavior. The biggest differences that stands out and can be a source of your device not responding properly is:

The second response does not have content (it does not present any data back to your device), as can be seen in the "Content-Length: 0" header compared to the "Content-Length: 30" header in the apache response.

answered 12 Sep '12, 03:35

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

There is indeed data, click on the "Line-based text data" line and watch the corresponding hex data being highlighted. Or do a "Follow TCP stream" on the response packet.

Then from the increasing port numbers it looks like there is a new TCP connection for every object being transferred, even though the default in HTTP/1.1 is to keep the connection open. Does the client or the server close the connection?

Can you post a capture file to www.cloudshark.org and paste the link to it here?

(You may want to use bittwiste to remove the IP adresses)

(12 Sep '12, 04:35) SYN-bit ♦♦

I am new to WireShark, and used "Export Packet Dissections as Plain Text File" to save the Capture for inspection in an editor. It appears that this Export option did not save the additional data which I now see is available. Your post has most certainly helped. Thank you.

(12 Sep '12, 05:36) oldevel

I converted your "answer" to a "comment" as that's how this site works best, please see the FAQ for details.

Also, if you feel your question is answered, it is customary to accept the answer that answered your question by clicking on the check-mark next to it. This also removes the question from the "Ananswered Questions" list and helps other people to find the answers to their similar questions.

(12 Sep '12, 05:44) SYN-bit ♦♦

I converted your second comment to an answer (I hope all is correct now). Once again thank you for your comments and advice.

(12 Sep '12, 06:13) oldevel

Actually, these were all comments to the same "answer" to keep the flow clear for others, it would have been better to leave that as a comment. But no worries... I don't think there will be more answers posted to this question (which will disrupt the flow, especially when people start liking answers which will change the order of answers).

(12 Sep '12, 06:30) SYN-bit ♦♦

Answer 2

Thank you for your response. I have copied a few more responses below. From these responses, which also correspond to some information on how the device communication should work, it appears that no data is sent back from the web endpoint (web server) to the device, only OK. One thing that is somewhat contradictory here is that the Len: and Content length: fields in these responses appear to indicate otherwise, yet no corresponding data is visible in either the Info fields.

No.     Time        Source                Destination           Protocol Length Info
      6 0.268032                                                HTTP     316    HTTP/1.1 200 OK  (text/plain)
Frame 6: 316 bytes on wire (2528 bits), 316 bytes captured (2528 bits)
Ethernet II, Src: …
Internet Protocol Version 4, Src: …
Transmission Control Protocol, Src Port: http (80), Dst Port: activesync (1034), Seq: 145, Ack: 180, Len: 250
[2 Reassembled TCP Segments (394 bytes): #5(144), #6(250)]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 200
Response Phrase: OK
Content-Length: 250\r\n
[Content length: 250]
Content-Type: text/plain\r\n
Date: Mon, 10 Sep 2012 13:15:07 GMT\r\n
Server: CherryPy/3.1.0beta3 WSGI Server\r\n
\r\n
Line-based text data: text/plain
No.     Time        Source                Destination           Protocol Length Info
16 6.532646                                                HTTP     68     HTTP/1.1 200 OK  (text/plain)
Frame 16: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Ethernet II, Src: …
Internet Protocol Version 4, Src: …
Transmission Control Protocol, Src Port: http (80), Dst Port: mxxrlogin (1035), Seq: 143, Ack: 231, Len: 2
[2 Reassembled TCP Segments (144 bytes): #15(142), #16(2)]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 200
Response Phrase: OK
Content-Length: 2\r\n
[Content length: 2]
Content-Type: text/plain\r\n
Date: Mon, 10 Sep 2012 13:15:13 GMT\r\n
Server: CherryPy/3.1.0beta3 WSGI Server\r\n
\r\n
Line-based text data: text/plain
No.     Time        Source                Destination           Protocol Length Info
28 9.592467                                                HTTP     96     HTTP/1.1 200 OK  (text/plain)
Frame 28: 96 bytes on wire (768 bits), 96 bytes captured (768 bits)
Ethernet II, Src: …
Internet Protocol Version 4, Src: …
Transmission Control Protocol, Src Port: http (80), Dst Port: nsstp (1036), Seq: 144, Ack: 257, Len: 30
[2 Reassembled TCP Segments (173 bytes): #27(143), #28(30)]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 200
Response Phrase: OK
Content-Length: 30\r\n
[Content length: 30]
Content-Type: text/plain\r\n
Date: Mon, 10 Sep 2012 13:15:16 GMT\r\n
Server: CherryPy/3.1.0beta3 WSGI Server\r\n
\r\n
Line-based text data: text/plain
No.     Time        Source                Destination           Protocol Length Info
38 33.427907                                               HTTP     68     HTTP/1.1 200 OK  (text/plain)
Frame 38: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Ethernet II, Src: …
Internet Protocol Version 4, Src: …
Transmission Control Protocol, Src Port: http (80), Dst Port: ams (1037), Seq: 143, Ack: 231, Len: 2
[2 Reassembled TCP Segments (144 bytes): #37(142), #38(2)]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 200
Response Phrase: OK
Content-Length: 2\r\n
[Content length: 2]
Content-Type: text/plain\r\n
Date: Mon, 10 Sep 2012 13:15:40 GMT\r\n
Server: CherryPy/3.1.0beta3 WSGI Server\r\n
\r\n
Line-based text data: text/plain