Subject: HTTP entity length

From: jordi ros <[email-masked]>
Date: Tue, 01 Feb 2000 10:34:12 -0800

Hi,

I would like to know how to get the length of the entity body for an
HTTP packet. I know that there is a header field called "content-lenght"
but that this one is not enough to get to know the actual length for any
possible case. Can anybody explain me what actions should be done in
order to derive the length of the entity body from the HTTP header
fields and for any possible situation?

Thanks a lot!

Jordi

--
Jordi Ros Giralt
Department of Electrical and Computer Engineering
University of California, Irvine
http://www.eng.uci.edu/~jros
phone: (949) 824 8491 (office) / (949) 725 6487 (home)

---

From: Patrick McManus <[email-masked]>
Date: Tue, 1 Feb 2000 13:44:09 -0500 (EST)

In a previous episode jordi ros said...

:: 
:: I would like to know how to get the length of the entity body for an
:: HTTP packet.

How to determine the length of the message body is the (exhaustive)
subject of section 4.4 of rfc 2616.

-P

---

From: jordi ros <[email-masked]>
Date: Wed, 02 Feb 2000 10:12:44 -0800

> subject of section 4.4 of rfc 2616.

Thanks !

I have gone through that part of the RFC and now a question arises to me.
Suppose the following case:

A- Our message includes a message-body, which means that condition 1 in
section 4.4 is false, and
B- There is no Transfer-Encoding, which means that condition 2 in 4.4 is
false, and
C- There is no Content-Length field, which means that condition 3 in 4.4 is
false (note that this is possible since from section 14.13 we have that
applications SHOULD (only SHOULD) use this field to indicate the
transfer-length when it is not prohibited by rules in section 4.4) and
D- The content-type is not "multipart/byteranges", which means that
condition 4 in 4.4 is false, and
E- The server is not closing the connection, which means that condition 5
is false.

I think that according to the RFC the previous situation may happen and, if
so (somebody may help me here), we cannot determine the transfer length
since 4.4 does not specify this case. I think that the key point is in the
SHOULD condition of section 14.13. If instead we use a MUST in this
section, then we can break condition C.
I would appreciate any comments, thanks!!!

Jordi

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 2 Feb 2000 13:38:18 -0500

> From: jordi ros

> D- The content-type is not "multipart/byteranges", which
> means that condition 4 in 4.4 is false, and
> E- The server is not closing the connection, which means
> that condition 5 is false.

Your point A is where the problem lies.

If you don't send a Content-Length, and you don't send a
'Transfer-Encoding: chunked', and your Content-Type is not some kind
of 'multipart', then your message does not include a message-body;
it ends at the CRLF following the last header.  If you are a client,
then anything you send following that will be interpreted as the
beginning of a new request; if you are a server then I have no idea
what clients might do.

SHOULD does not mean 'you can ignore this rule' - it means that you
don't have to do it to be compliant, but you aught to unless there
is an excellent reason.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 02 Feb 2000 11:22:19 -0800

>beginning of a new request; if you are a server then I have no idea

That applies to request messages only.  For responses other than
those required not to have a body, the message body includes
anything that appears after the header fields until the connection
is closed.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 02 Feb 2000 11:29:42 -0800

>I think that according to the RFC the previous situation may happen and, if

No, it cannot.  The specification says "one of the following".  There is
no option beyond that.  The server will eventually close the connection
and thereby will end the body.  The RFC is making a factual statement.

....Roy