We don't have any sample app for this.
You might be interested to know that the Servlet EG is considering standardizing the handling of 100-Continue requests, as described by the following proposal sent by Servlet EG member Greg Wilkins:
----------------------------------------------------------------------------------------------------------------------------
The servlet needs to take no action in order for a 100 continues
response to be sent, other than call getInputStream(). The servlet
never need do a setStatus(100), as calling getInputStream is sufficient
to signal that the servlet is willing to read content.
So the sequence of events is either:
1) request header with Expect: 100-Continue arrives
client does not send content as it is waiting for 100 response.
2) server dispatches request to servlet
3) servlet reads uri/headers
4) servlet calls request.getInputStream (or getWriter or parameter methods)
causing server sends a 100 continues response
5) servlet blocks reading on the input stream
6) request body content arrives
inputStream is unblocked and content is read.
7) normal response is generated.
OR
1) request header with Expect: 100-Continue arrives
client does not send content as it is waiting for 100 response.
2) server dispatches request to servlet
3) servlet reads uri/headers
4) servlet generates a response with sendError, sendRedirect or
normal response processing.
5) client receives response and never sends the content.
What I have seen other servers do is to send the 100 continues response
as soon as they see the expect header. This approach delays that until
the servlet has indicated that it wishes to process content.
[Message sent by forum member 'jluehe' (jluehe)]
http://forums.java.net/jive/thread.jspa?messageID=286832