users@grizzly.java.net

Re: Expect: 100-continue

From: Ryan Lubke <ryan.lubke_at_oracle.com>
Date: Fri, 15 Jul 2011 15:26:54 -0700

On 7/15/11 2:57 PM, Jon Brisbin wrote:
> I'm just using curl to upload a file and it does manually set the
> Expire: 100-continue header.

Right. I understood that from your original mail. Please see:

-------------------------------------------------------
If you don't try to handle this yourself, does the upload work? Have
you used something like wireshark or ngrep to ensure the "conversation"
between the user-agent and the server are as you would expect it for
this use case?
-------------------------------------------------------

i.e., if you monitor the packets, do you see 100-CONTINUE returned from
the Server followed by the user-agent sending the request body?

>
> Sent from my iPhone
>
> On Jul 15, 2011, at 4:29 PM, Ryan Lubke <ryan.lubke_at_oracle.com
> <mailto:ryan.lubke_at_oracle.com>> wrote:
>
>> On 7/15/11 1:47 PM, Jon Brisbin wrote:
>>> I'm writing an HTTP REST server in Grizzly and curl wants to send an
>>> "Expect: 100-continue" header by default.
>>>
>>> I'm not at all sure how to handle this on the Grizzly end. When I
>>> guessed at what to do and sent a 100 response, the body of my upload
>>> was always blank.
>>>
>>> Any suggestions on how I need to handle 100-continue responses when
>>> accepting HTTP/1.1 uploads in Grizzly?
>>>
>>>
>>> Thanks!
>>>
>>> Jon Brisbin
>>> http//jbrisbin.com
>>>
>>>
>>
>> HttpHandler.sendAcknowledgement() (line 311) has behavior to handle
>> this. This method can be overridden by custom handlers to customize
>> the behavior. This method is called at line 137. So this should be
>> handled for you.
>>
>> However, there is a case where this acknowledgement process will be
>> ignored - this will occur when the user-agent sents the POST/PUT with
>> the Expect header and includes content from the request body.
>>
>> If you don't try to handle this yourself, does the upload work? Have
>> you used something like wireshark or ngrep to ensure the
>> "conversation" between the user-agent and the server are as you would
>> expect it for this use case?
>>
>> [1] *http://tinyurl.com/6aoknz4*