Thanks James.
I was about to rant at you about the section Practical Considerations
but I realised, in the nick of time, that they have updated the spec
to clarify the point.
Good. Thanks again.
Nic
>>> James Duncan Davidson <[EMAIL PROTECTED]> 4/2/99
10:31:08 PM >>>
> 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
___________________________________________________________________________
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
