Does JRE HttpServer violates the 'expect-continue' semantics of HTTP?

Question

This is a follow up post to some problems I've had using Java built in com.sun.net.httpserver.HttpServer and an multistep authentication scheme.

I was hinted at, that sending larger data amounts make it impossible for Java clients to receive early "Authorization required"-messages (due to Java blocking I/O).

Thats the reason why HTTP defines the "expect-continue handshake" involving 100 status code (RFC 2616):

The purpose of the 100 (Continue) status is to allow a 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.

So in this case it is not appropriate to send the data. The server...

MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code.

Unfortunately the Sun HttpServer always responds with a 100 status code without involving the application. Looking at the source:

/* check if client sent an Expect 100 Continue.
 * In that case, need to send an interim response.
 * In future API may be modified to allow app to
 * be involved in this process.
 */
String exp = headers.getFirst("Expect");
if (exp != null && exp.equalsIgnoreCase ("100-continue")) {
    logReply (100, requestLine, null);
    sendReply (
        Code.HTTP_CONTINUE, false, null
    );
}

When the application is not involved, its seems to be not possible to communicate the client that it is inappropriate to send its message thus the protocol is violated (which really leads to problems like early closed connections and broken pipes). Just in case I'm missing something, I better ask the community if this interpretation is right :)

Answer 1

I wouldn't say it is violating the protocol, because communicating between the server and the application is not part of the protocol, only communicating between the server and the client. As long as the server accepts the entire client request after sending a 100-Continue, the protocol is respected.

Of course, automatically returning the 100-Continue means you lose the potential efficiency gain that Expect-Continue is intended to provide, but efficiency is not what the protocol guarantees.