Comment # 7
on bug 12411
from Guy Harris
(In reply to Dmitriy from comment #4)
> Jaap Keuter:
>
> > The entire HTTP message is decoded properly, as soon as the *full* HTTP
> > message is seen, which can only mean the final TCP fragment.
>
> Are you referring to the FIN flag in the final TCP fragment?
No. He's referring to the last of the TCP segments that contain data from the
HTTP message.
As TCP is a byte-stream protocol, there's nothing that TCP offers, other than
FIN, to indicate boundaries within that stream, so, unless a protocol works by
opening a connection, sending a message (or a file, as in an FTP DATA
connection), and closing the connection, so that there is only one message
sent, a protocol running atop TCP needs to provide its own message boundaries.
One way to do this is to have a "message length" that appears somewhere in the
beginning of the message, so that the receiver can count received bytes and
determine where the message ends.
Another way to do this is to have some separators in the message contents.
HTTP uses a mixture of those. Following the request or response line is a
sequence of header lines; a blank line is a separator indicating the end of the
header lines and the beginning of the message body. One of those header lines
is Content-Length:, which contains the length of the message body, in bytes; if
that header is present, the receiver knows that it needs to process that many
bytes of message body. The body could also be transferred using chunked
transfer encoding:
https://en.wikipedia.org/wiki/Chunked_transfer_encoding
which uses a zero-length chunk as a separator. And, if neither of those are
used, a FIN can indicate the end of the body (and of that side of the
connection).
You are receiving this mail because:
- You are watching all bug changes.