Hi Jon,
Ryan took a short vacation, so I'll try to respond...
> curl is reporting the 100 response only when I send it manually.
>
> * About to connect() to localhost port 8080 (#0)
> * Trying ::1... connected
> * Connected to localhost (::1) port 8080 (#0)
> > PUT /bucket/textfile.txt HTTP/1.1
> > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
> OpenSSL/0.9.8l zlib/1.2.3
> > Host: localhost:8080
> > Accept: */*
> > Content-Type: text/plain
> > Content-Length: 12
> > Expect: 100-continue
> >
> < HTTP/1.1 100 Continue
> < content-type: text/html; charset=iso-8859-1
> < Connection: close
> < Date: Mon, 18 Jul 2011 13:20:47 GMT
> < content-length: 0
> ^C
>
> which is coming from:
>
> if (httpContent.httpHeader.expectContent) {
> send(100, false, ctx, httpContent, ["Content-Length": 0])
> return stop
> }
>
> If I pull out the content before sending the 100, it is empty, which
> doesn't make much sense as curl is sending the content-length of 12
> (which I assume means its sending the content).
With "Expect: 100-continue" it's not (though still possible).
You can find additional description here [1], but the main usecase for
100-continue is to check whether server wants to accept coming HTTP
request payload based on the request headers.
So first client sends just request headers and wait whether server will
respond 100 Continue, if yes - client sends actual payload, if not - it
doesn't.
> But after I manually send a 100 response, I have no idea what's
> supposed to happen. Will handleRead be called again with a new
> HttpContent message?
Yes.
I'd probably recommend to use higher level grizzly-http-server API [2],
so by default you shouldn't even care about 100-continue, Grizzly will
handle it for you.
Thanks.
WBR,
Alexey.
[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html (8.2.3)
[2]
http://grizzly.java.net/nonav/docs/docbkx2.0/html/http-server-framework.html
>
> This is new territory for me and I have no idea how to use wireshark.
> I tried to figure it out for a while but I'm not a network guy, so
> that low level stuff is fairly opaque to me.
>
> Thanks!
>
> Jon Brisbin
> http//jbrisbin.com
>
>
> ------------------------------------------------------------------------
>
> *From: *"Ryan Lubke" <ryan.lubke_at_oracle.com>
> *To: *users_at_grizzly.java.net
> *Sent: *Friday, July 15, 2011 5:26:54 PM
> *Subject: *Re: Expect: 100-continue
>
> 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*
>
>
>