> From: Marty Joel [mailto:mjoel at 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 at process.com