IPP Mail Archive: RE: IPP> Multipart Chunked Keep-Alive?

IPP Mail Archive: RE: IPP> Multipart Chunked Keep-Alive?

RE: IPP> Multipart Chunked Keep-Alive?

From: Mike Bartman (bartman@process.com)
Date: Sat Aug 04 2001 - 11:21:23 EDT

  • Next message: Marty Joel: "IPP> Object Persistence"

    > From: Marty Joel [mailto:mjoel@netreon.com]
    >
    > I'm a bit rusty on HTTP, so maybe someone can help me out.
    > Please correct me if I'm wrong below.
    >
    > A Sender may choose to use keep-alive (not use Connection: Close), and
    > doing so allows a connection to be reused for one request/reply after
    > another, each preceded by HTTP header lines and a blank line.
    > Either side
    > may end a TCP connection (keep-alive or otherwise) by cleanly
    > closing the
    > connection (using a handshaked close to prevent the long
    > abnormal close timeout period).

    You were good up to that last bit. I think you are crossing the HTTP 1.1
    "close handshake" with the TCP/IP one. If a connection is "persistent"
    (keep-alive is a term easily confused with lower level protocol options...),
    then it can be closed after a transaction is *completed* (i.e. a response
    has been sent), IF the last message on the link from the "closer" contained
    a "Connection: close" header line...i.e. if proper HTTP 1.1 notification was
    given of the intent to close the connection. If a connection closes
    *without* that notification on an HTTP 1.1 link, then it is probably an
    error situation (or a non-compliant implementation...a different sort of
    error condition ;^). From RFC 2068:

       ===========
       HTTP/1.1 defines the "close" connection option
       for the sender to signal that the connection will be closed after
       completion of the response. For example,

              Connection: close

       in either the request or the response header fields indicates that
       the connection should not be considered `persistent' (section 8.1)
       after the current request/response is complete.

       HTTP/1.1 applications that do not support persistent connections MUST
       include the "close" connection option in every message.
       ===========

    Also:

       ===========
    8.1.2 Overall Operation

       A significant difference between HTTP/1.1 and earlier versions of
       HTTP is that persistent connections are the default behavior of any
       HTTP connection. That is, unless otherwise indicated, the client may
       assume that the server will maintain a persistent connection.
       ===========

    I have run into IPP 1.0 implementations that do not support persistent
    connections and do not properly notify of impending link closures (this from
    a major manufacturer too). I've had to implement an option in my client so
    that system managers can tell the client that they are dealing with such a
    server so the client can tell the difference between an error condition and
    an intentional link closure. In the former case I requeue the job to be
    tried again at a later time, and in the later case I just open another link
    and proceed with the printing.
     
    > Where does HTTP's chunked fit into this? As I understand it,
    > chunking is
    > used when a large amount of data must be sent in a single
    > HTTP request or
    > reply, where each chunk is preceded by a chunk header that
    > contains the
    > number of bytes in the following chunk. Chunked would
    > typically only be used when sending a document.

    Not quite. Chunking is intended for cases where the total length of a
    message can not be determined at the time the HTTP header is transmitted.
    When a web page is being generated "on the fly" for example. You can
    specify chunking, send the header, then send each part of the response as it
    is generated, then signal "that's all!" when you know you've sent it all.
    Chunking may also be removed by the transmission linkage if it wants
    to...for example a proxy server could convert a chunked message into a
    non-chunked message, so using chunking for anything other than occasional
    convenience is a bad idea.

    Again from RFC 2068:

       ===========
    3.6 Transfer Codings

       Transfer coding values are used to indicate an encoding
       transformation that has been, can be, or may need to be applied to an
       entity-body in order to ensure "safe transport" through the network.
       This differs from a content coding in that the transfer coding is a
       property of the message, not of the original entity.

              transfer-coding = "chunked" | transfer-extension

              transfer-extension = token
       ===========

    Despite the fact that chunking is a required part of HTTP 1.1, and IPP 1.0
    uses HTTP 1.1, I've run into servers that don't do chunking...which is a
    real PITA for me doing printing, since *all* of my stuff is generated "on
    the fly" by the formatting parts of the client. The only way I can know up
    front how long a Print-Job message will be is to spool the job, then read it
    back once I have it all. This slows printing considerably when the link is
    fast and the server has a large buffer, since the spooling adds a lot of
    disk activity to the process. It's easy to say, "if it isn't compliant,
    just don't print to it", but in practical, angry customer, terms, we need to
    print anyway if there's any way at all to do so, so I have to treat chunking
    as optional, despite the hassle and performance problems.

    Just FYI, here's the RFC 2068 stuff on chunking requirements:

       ===========
       All HTTP/1.1 applications MUST be able to receive and decode the
       "chunked" transfer coding, and MUST ignore transfer coding extensions
       they do not understand. A server which receives an entity-body with a
       transfer-coding it does not understand SHOULD return 501
       (Unimplemented), and close the connection. A server MUST NOT send
       transfer-codings to an HTTP/1.0 client.
       ===========

    > Can multipart and chunking coexist?

    I don't see any reason why they couldn't. Chunking is a transmission level
    issue, multipart is above that. Chunking is how you get a block of bytes
    from point A to point B, while multipart is a question of what that block of
    bytes looks like.

    -- Mike Bartman
       Process Software
       bartman@process.com



    This archive was generated by hypermail 2b29 : Sat Aug 04 2001 - 11:23:14 EDT