On 2/3/11 9:51 AM, Tim Quinn wrote:
> 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?
I don't think when you called getOutputStream() would matter with the
current implementation.
>
> 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?
That's where the 100-Continue implementation would be useful.
The client, in addition to all of the other typical headers you're
setting would set an additional header
of Expect with a value of 100. Then, on the server side you would make
sure the request falls within
whatever constraints you may have (say a max upload size, or
authentication requirements).
Here, is when you'd do the authentication check on the server side. If
the authentication check succeeds,
the 100 Continue response is sent back to the client which at that point
the upload could begin.
>
> 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.
I think this blog entry [1] sums it up.
[1]
http://blogs.sun.com/jcc/entry/httpurlconnection_and_100_continue
>
> Thanks.
>
> - Tim
>