0

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 :)

Community
  • 1
  • 1
mtsz
  • 2,725
  • 7
  • 28
  • 41

1 Answers1

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.

antlersoft
  • 14,636
  • 4
  • 35
  • 55
  • 1
    As an addendum to this great answer, i would add that the sun HttpServer has a _very_ limited use scope. for any _real_ webserver needs you should use something like jetty, apache, or the host of other high quality java webservers. – jtahlborn Feb 08 '12 at 16:45
  • @jtahlborn The project this server is embedded is an academic context, so afaik there have been other considerations to use this one, like the fact that it is part of java. I have to admit the Jetty should be a better decision, since almost no one uses the sun httpserver anyways for anything serious. – mtsz Feb 08 '12 at 17:32
  • @antlersoft Thanks for your answer, but the server is not willing to accept the request after the 100 was sent, because the client is not authorized yet. This is an intented use case according to http://www8.org/w8-papers/5c-protocols/key/key.html . There is no way to communicate the sun httpserver that it should avoid sending the continue message in this case. But yeah, its not the core-protocol, its just the periphery for bandwidth optimization. Maybe it is inappropriate to call it violation or not... and probably not interesting anyway... the question does not seem to have much friends :) – mtsz Feb 08 '12 at 18:02