Sorry I'm not all that familiar with these uber-low-level things. I have no idea what this conversation is "supposed" to look like. I've never had to deal with the Expect header before.
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).
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?
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
----- Original Message -----
> 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 >
> > 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
> >
>