The spec states that practically all HTTP/1.1 responses should be
chunked unless Content-Length is applied when using
persistent-connections.
Here is Section 3.6:
Whenever a transfer-coding is applied to a message-body, the set of
transfer-codings MUST include "chunked", unless the message is
terminated by closing the connection. When the "chunked"
transfer-
coding is used, it MUST be the last transfer-coding applied to
the
message-body.
>From 8.1.2.1:
In order to remain persistent, all messages on the connection
MUST
have a self-defined message length (i.e., one not defined by
closure
of the connection), as described in section 4.4.
>From 4.4:
The transfer-length of a message is the length of the message-body
as
it appears in the message; that is, after any transfer-codings
have
been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the
following
(in order of precedence):
1.Any response message which "MUST NOT" include a message-body
(such
as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present
in
the message.
2.If a Transfer-Encoding header field (section 14.41) is present
and
has any value other than "identity", then the transfer-length
is
defined by use of the "chunked" transfer-coding (section 3.6),
unless the message is terminated by closing the connection.
3.If a Content-Length header field (section 14.13) is present,
its
decimal value in OCTETs represents both the entity-length and
the
transfer-length. The Content-Length header field MUST NOT be
sent
if these two lengths are different (i.e., if a
Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header
field,
the latter MUST be ignored.
4.If the message uses the media type "multipart/byteranges", and
the
transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media
type
MUST NOT be used unless the sender knows that the recipient can
parse it; the presence in a request of a Range header with
multiple byte-range specifiers from a 1.1 client implies that
the
client can parse multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1,3 or 5 of
this section.
5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since
that
would leave no possibility for the server to send back a
response.
Therefore we can see that the easisest way to achieve persistent
connections is for the server to encode ALL http1.1 output with
chunked encoding (this should be more efficient anyway) and to handle
the persistent connection as simply a matter of request/response
headers.
BTW most servers that I know of were buffering output (to an extent)
anyway in order to apply a Content-Length.
For example: Paperclips buffers a user-definable amount (default:
20K) before leaving off the Content-Length header.
Nic
>>> Murthy Chintalapati <[EMAIL PROTECTED]> 4/3/99
2:17:19 AM >>>
James,
> So, as you can see -- status codes have *nothing* to do with
persistent
> connections, only with making sure that 1) the server sets and
> interprets the right headers and 2) all messages must have
defined
> content lengths.
>
Just wanted to add to the 2) .. either all the messages have defined
content lengths or follow the chunked-encoded response scheme for
HTTP/1.1.
Now, if a servlet does not set the Content-Length: header, then is
it
Server's responsibility to do chunking automatically on a Keep-Alive
connection? Server could close the connection, but that defeats the
purpose
of HTTP/1.1 persitent connections.
Thanks!
cvr
> Date: Fri, 02 Apr 1999 13:31:08 -0800
> From: James Duncan Davidson <[EMAIL PROTECTED]>
> Subject: Re: YAMQ (Yet Another Implementation Question)
> To: [EMAIL PROTECTED]
> Content-transfer-encoding: 7bit
> X-Accept-Language: en
>
> > The correct reply to a request which is made on a socket
connection
> > which is going to be made persistent is:
> >
> > 100 - Continue.
>
> SC 100 has nothing to do whith "keep alive"..
>
> Quote from the HTTP/1.1 spec:
>
> "8.2.4 Use of the 100 (Continue) Status
>
> The purpose of the 100 (Continue) status (see section 10.1.1) is
to
> allow an end-client that is sending a request message with a
request
> body to determine if the origin server is willing to accept the
> request (based on the request headers) before the client sends
the
> request body. In some cases, it might either be inappropriate or
> highly inefficient for the client to send the body if the server
will
> reject the message without looking at the body."
>
> The section that has to do with Keep Alive type functionality is:
>
> "8.1.2.1 Negotiation
>
> An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
> maintain a persistent connection unless a Connection header
including
> the connection-token "close" was sent in the request. If the
server
> chooses to close the connection immediately after sending the
> response, it SHOULD send a Connection header including the
> connection-token close.
>
> An HTTP/1.1 client MAY expect a connection to remain open, but
would
> decide to keep it open based on whether the response from a
server
> contains a Connection header with the connection-token close. In
case
> the client does not want to maintain a connection for more than
that
> request, it SHOULD send a Connection header including the
connection-
> token close.
>
> If either the client or the server sends the close token in the
> Connection header, that request becomes the last one for the
> connection.
>
> Clients and servers SHOULD NOT assume that a persistent connection
is
> maintained for HTTP versions less than 1.1 unless it is
explicitly
> signaled. See section 19.6.2 for more information on backward
> compatibility with HTTP/1.0 clients.
>
> In order to remain persistent, all messages on the connection
MUST
> have a self-defined message length (i.e., one not defined by
closure
> of the connection), as described in section 4.4."
>
> So, as you can see -- status codes have *nothing* to do with
persistent
> connections, only with making sure that 1) the server sets and
> interprets the right headers and 2) all messages must have
defined
> content lengths.
>
> .duncan
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives:
http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
............................................................................
Murthy Chintalapati [EMAIL PROTECTED]
(650)786-3676
"Expression Purifies
Thought"
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources:
http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
