dev@grizzly.java.net

Looking ahead - a more permanent solution to the renegotiation-with-payload problem

From: Tim Quinn <tim.quinn_at_oracle.com>
Date: Thu, 3 Feb 2011 11:51:38 -0600

Hi, everyone.

I *think* I finally understand from Ryan and Alexey why we had the
problem with large payloads over SSL when no client cert was sent.

One suggestion for a longer-term solution would be to use the 100-
Continue status. I have not worked with 100 before so I tried to read
a little about it.

Along the way, I was reviewing exactly what the admin client does today.

1. Open the connection.
2. Set headers.
3. Write the payload.
4. Connect.
5. If redirected, close connection and repeat from #1 with https
instead.

Could part of the problem we had be that the client writes the payload
before connecting?

Should getOutputStream and write to it only after connecting? Would
that even work? Would that have avoided the problem of renegotiation
with a large payload?

How would the client make sure that the request (omitting the payload)
reached the server so any renegotiation could take place before the
client wrote the payload?

I also understood that there might be some problems with the Java SE
implementation of 100 support. I'm curious to know more about those
limitations if someone can summarize them or point me to other
information.

Thanks.

- Tim