Why use Content-length? - TCP-IP

This is a discussion on Why use Content-length? - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Why use Content-length?

  1. Why use Content-length?

    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.

    What is the size in the Content-Header generally used for on the server
    side?


  2. Re: Why use Content-length?

    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.



  3. Re: Why use Content-length?

    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 ***

  4. Re: Why use Content-length?


    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


  5. Re: Why use Content-length?


    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

  6. Re: Why use Content-length?


    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

+ Reply to Thread