Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3FA6CAF2.905@finemaltcoding.com>
Date: Mon, 03 Nov 2003 13:38:58 -0800
From: Daniel Rall <dlr@finemaltcoding.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701
MIME-Version: 1.0
Followup-To: dlr@apache.org,gstein@lyra.org
To: tomcat-dev@jakarta.apache.org
CC: slide-dev@jakarta.apache.org, Greg Stein <gstein@lyra.org>
Subject: Servlet API support for multiple HTTP status codes (1xx)?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Question
--------
How to send multiple 1xx responses and a final 200 response to a single request?


An example
----------
A HTTP/1.1 user agent (UA) sends a large, multi-GB XML data file to your server. 
  Thirty seconds pass and the server is still digesting the data file.  The 
server responds with a 100 status code to inform the UA to continue waiting. 
Another 30 seconds pass -- rinse, repeat ten more times over the same HTTP 
connection.  Withouth the 1xx responses, a UA like MS IE or Mozilla would've 
timed out the request by now.  Seven more seconds pass and the server finally 
gets back to the UA with the real response -- a fancy PDF-formatted graphical 
representation of their XML file, perhaps.


Some background
---------------
HTTP/1.1 (RFC 2616) [1] defines informational status codes as those in the 1xx 
range, and indicates that HTTP/1.1 UAs must be prepared to accept many such 
intermediate responses before the final response (to the single, original request).

Here's the relevant section from RFC 2616:

10.1 Informational 1xx

    This class of status code indicates a provisional response,
    consisting only of the Status-Line and optional headers, and is
    terminated by an empty line. There are no required headers for this
    class of status code. Since HTTP/1.0 did not define any 1xx status
    codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
    except under experimental conditions.

    A client MUST be prepared to accept one or more 1xx status responses
    prior to a regular response, even if the client does not expect a 100
    (Continue) status message. Unexpected 1xx status responses MAY be
    ignored by a user agent.

    Proxies MUST forward 1xx responses, unless the connection between the
    proxy and its client has been closed, or unless the proxy itself
    requested the generation of the 1xx response. (For example, if a
    proxy adds a "Expect: 100-continue" field when it forwards a request,
    then it need not forward the corresponding 100 (Continue)
    response(s).)

10.1.1 100 Continue

    The client SHOULD continue with its request. This interim response is
    used to inform the client that the initial part of the request has
    been received and has not yet been rejected by the server. The client
    SHOULD continue by sending the remainder of the request or, if the
    request has already been completed, ignore this response. The server
    MUST send a final response after the request has been completed. See
    section 8.2.3 for detailed discussion of the use and handling of this
    status code.


WebDAV extensions to HTTP/1.1 (RFC 2518) [2] continues definition of 
informational status codes with 102 (Processing) as a way for the server to 
provide "yes I'm still working so hold your horses" feedback to the UA when 
dealing with long-lived requests.  Using our XML -> PDF example from above, this 
is a bit more descriptive than "continue waiting" 100 response, indicating not 
just that the UA should wait, but also that the server is indeed working on 
proessing the request.  Here's the relevant section:

10.1 102 Processing

    The 102 (Processing) status code is an interim response used to
    inform the client that the server has accepted the complete request,
    but has not yet completed it.  This status code SHOULD only be sent
    when the server has a reasonable expectation that the request will
    take significant time to complete. As guidance, if a method is taking
    longer than 20 seconds (a reasonable, but arbitrary value) to process
    the server SHOULD return a 102 (Processing) response. The server MUST
    send a final response after the request has been completed.

    Methods can potentially take a long period of time to process,
    especially methods that support the Depth header.  In such cases the
    client may time-out the connection while waiting for a response.  To
    prevent this the server may return a 102 (Processing) status code to
    indicate to the client that the server is still processing the
    method.


Servlet API lacking?
--------------------
Brief examination of the source for Tomcat 4.1 leads me to believe that though 
sendError(int) does provide a way for communicating informational responses in 
the 1xx range -- which incidently aren't error conditions -- that later attempts 
to communicate additional 1xx or the final 200 response are not supported, and 
result in an IllegalStateException or IOException or some such.  Without writing 
code directly against Tomcat's own API to gain access to the underlying TCP 
socket connection (rather than against the more portable Servlet API), I'm not 
seeing a way of sending multiple interim responses to the UA.  Is Servlet API 
2.3 really lacking this feature, or did I just miss it somewhere?  If so, is 
this feature planned for future versions of the Servlet API, and is there an 
interim work-around?


Thanks for your time,
Dan

p.s. Please CC me on any responses.


[1] http://www.ietf.org/rfc/rfc2616.txt

[2] http://www.ietf.org/rfc/rfc2518.txt


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org