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