[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 4 on bug 11104 from Guy Harris

RFC 2616:

    http://tools.ietf.org/html/rfc2616

says in section 5 "Request":

    http://tools.ietf.org/html/rfc2616#page-35

that a Request is:

        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

so that part of the grammar allows, but does not require, a message-body.

Section 9.3 "GET":

    http://tools.ietf.org/html/rfc2616#section-9.3

does not indicate whether a message-body is allowed for a GET request (it's not
*required*).

Section 4.3:

    http://tools.ietf.org/html/rfc2616#section-4.3

says

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MUST NOT be included in
   a request if the specification of the request method (section 5.1.1)
   does not allow sending an entity-body in requests. A server SHOULD
   read and forward a message-body on any request; if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.

Section 4.4:

    http://tools.ietf.org/html/rfc2616#section-4.4

says:

   The transfer-length of a message is the length of the message-body as
   it appears in the message; that is, after any transfer-codings have
   been applied. When a message-body is included with a message, the
   transfer-length of that body is determined by one of the following
   (in order of precedence):

   1.[some response messages must never have a message-body]

   2.[if Transfer-Encoding, and not "identity", it's chunked, and, with chunked
encoding, there's an end indicator]

   3.[if Content-Length, that tells you how many bytes of message-body there
are]

   4.[if Content-Type is multipart/byteranges, it's self-delimiting]

   5.By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)


where 5. seems to suggest that if there's no chunked transfer encoding,
Content-Length, or multipart/byteranges Content-Type in a request, there is no
message-body.

However, as I read section 3.5 "Closing a Connection" of RFC 793:

    http://tools.ietf.org/html/rfc793#section-3.5

  Case 2:  TCP receives a FIN from the network

    If an unsolicited FIN arrives from the network, the receiving TCP
    can ACK it and tell the user that the connection is closing.  The
    user will respond with a CLOSE, upon which the TCP can send a FIN to
    the other TCP after sending any remaining data.  The TCP then waits
    until its own FIN is acknowledged whereupon it deletes the
    connection.  If an ACK is not forthcoming, after the user timeout
    the connection is aborted and the user is told.

one side of a connection can close that side and still allow the other side to
send additional data, so I'm not sure why the *client* "closing the connection"
"would leave no possibility for the server to send back a response", and, as
it's the *client* sending the GET request, it could send it and close its side
of the connection with a FIN, and the server could then send back its reply and
send its own FIN when done (as it's not going to get any further requests from
the client, as the client->server side of the connection is closed.

On the other other hand, I've Telnetted to plenty of HTTP servers and typed in
HTTP 1.0 requests (I'm lazy and don't want to have to type a Host: header), and
the servers respond as soon as I've typed the two blank lines at the end of the
header.

So what we should probably do in the HTTP-style request/response reassembly
code (epan/req_resp_hdrs.c) is, for requests, not look for or reassemble a
message-body if we're reassembling a request and we:

    1) don't have a chunked transfer encoding;

    2) don't have a Content-Length header;

    3) don't have a multipart/byteranges content type.

---

      You are receiving this mail because:

• You are watching all bug changes.