The most obvious that comes to mind is for the client or server know if they
can accept the amount of data before transmitting it.

E.g. you can determine if there is enough disk space before you actually
transfer a file, thus saving bandwith in case one is short on storage.

In article <1158067273.176896.151240@e63g2000cwd.googlegroups. com>,
"samer" wrote:

> I have a client in java that can execute a PUT command. The size of the
> payload gets calculated in bytes and entered in the Content-Length
> header.
>
> But what is the advantage of this header? When I send a message to my
> server it could just as easily calculate the size of the payload.

How does it calculate this?

There are three ways to indicate the end of the payload in HTTP 1.1:

1) Send a Content-Length header.

2) Use Transfer-Encoding: chunked. The end of the payload is indicated
by a zero-length chunk.

3) Close the connection at the end of the payload.

I guess you're assuming #3, but that prevents use of persistent
connections, which are generally desirable.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:

> How does it calculate this?
>
> There are three ways to indicate the end of the payload in HTTP 1.1:
>
> 1) Send a Content-Length header.
>
> 2) Use Transfer-Encoding: chunked. The end of the payload is indicated
> by a zero-length chunk.
>
> 3) Close the connection at the end of the payload.
>
> I guess you're assuming #3, but that prevents use of persistent
> connections, which are generally desirable.

The other problem with #3 is that there is a somewhat greater risk that
a partial transfer will appear valid. If someone reboots a firewall or
shuts down a proxy, the TCP connection between the client and server
might close without error but too soon.

DS

In article , Barry Margolin writes:
> In article <1158067273.176896.151240@e63g2000cwd.googlegroups. com>,
> "samer" wrote:
>
> > I have a client in java that can execute a PUT command. The size of the
> > payload gets calculated in bytes and entered in the Content-Length
> > header.
> >
> > But what is the advantage of this header? When I send a message to my
> > server it could just as easily calculate the size of the payload.
>
> How does it calculate this?
>
> There are three ways to indicate the end of the payload in HTTP 1.1:
>
> 1) Send a Content-Length header.
>
> 2) Use Transfer-Encoding: chunked. The end of the payload is indicated
> by a zero-length chunk.
>
> 3) Close the connection at the end of the payload.
>
> I guess you're assuming #3, but that prevents use of persistent
> connections, which are generally desirable.

HTTP/1.1 does not allow #3 to delimit the end of the request, which
is what the OP's asking about. (It could be done, using a half-
close, but HTTP/1.1 pretends half-close doesn't exist; it assumes
a symmetric connection.)

HTTP/1.1 allows a fourth method: self-delimiting content using
the multipart/byteranges content-type. See RFC 2616 3.7.2 and
4.4 #4.

(4.4 #4 is the section which is infamously missing the first letter
of several words, including in the excellent phrase "unless the
sender knows that the recipient can arse it".)

--
Michael Wojcik michael.wojcik@microfocus.com

Every allegiance to some community eventually involves such a fetish,
which functions as the disavowal of its founding crime: is not 'America'
the fetish of an infinitely open space enabling every individual to
pursue happiness in his or her own way? -- Slavoj Zizek

In article <1158113486.793893.101490@i42g2000cwa.googlegroups. com>, "David Schwartz" writes:
> Barry Margolin wrote:
>
> > There are three ways to indicate the end of the payload in HTTP 1.1:
> >
> > ...
> >
> > 3) Close the connection at the end of the payload.
> >
> > I guess you're assuming #3, but that prevents use of persistent
> > connections, which are generally desirable.
>
> The other problem with #3 is that there is a somewhat greater risk that
> a partial transfer will appear valid. If someone reboots a firewall or
> shuts down a proxy, the TCP connection between the client and server
> might close without error but too soon.

Indeed. This is also a problem with HTTP agents that close the
connection to indicate the end of a chunked transfer, without sending
a zero-length chunk. I asked about this infelicitious (but apparently
quite common) behavior some weeks back, and the general consensus
seems to be that it's compliant. It's a terrible idea, though.

Besides accidental conversation termination, there's the possibility
of a maliciously-injected FIN. The sender would know there were
problems (as its subsequent sends would produce RSTs), but the
recipient would not.

TCP conversation termination is a lousy way to delimit messages. The
session layer shouldn't be responsible for determining message length.

--
Michael Wojcik michael.wojcik@microfocus.com

Even if Jesus set up a blogging cafe in the center of Rockport, Texas
and extolled the virtues of a woman's right to choose while snapping
pictures of gay weddings with his Nokia, it would have made no
difference to this election. -- Ashlee Vance