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]
