Sangjin Lee wrote:
Thanks much for taking care of this Rick! Shall we move the bug to
ASYNCWEB like the last time?
Yes, we probably should. I got sidetracked on some other stuff today,
and didn't get a chance to do it? Do you have time to generate a patch
for the asyncweb tree?
Rick
Regards,
Sangjin
On Feb 12, 2008 3:43 PM, Sangjin Lee <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I just submitted a patch that includes Rick's fixes as well as the
fix that addresses the content issue. Please review and apply the
patch if you're OK with it... Thanks!
Sangjin
On Feb 12, 2008 1:01 PM, Rick McGuire <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Sangjin Lee wrote:
> I'm getting the patch ready for this... Would a separate bug be
> needed or shall we use the existing bug but modify it? A
single patch
> will address both issues...
I think we can use the already existing one. That patch has
not been
committed to the codebase yet.
Rick
>
> Thanks,
> Sangjin
>
> On Feb 12, 2008 11:12 AM, Rick McGuire <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> Sangjin Lee wrote:
> > While looking at an issue related with a form post
> (GERONIMO-3839), I
> > found an even more glaring issue. Namely, any
caller-supplied
> request
> > body is ignored by HttpRequestEncoder. For example,
you may want to
> > do a simple file upload using an octet stream. One
can set the
> > content using HttpMessage.addContent(byte[]).
> I sort of wondered about that hard-coded content type
when I was
> working
> on the header changes. I'm glad it bothered somebody
else enough to
> investigate.
>
> Rick
>
> >
> > However, HttpRequestEncoder makes a specific
assumption that all
> post
> > requests are form posts. Therefore, it ignores any
message
> body, and
> > simply encodes the form into the body. We need to be
able to handle
> > this properly. I'll file a bug shortly...
> >
> > Thanks,
> > Sangjin
> >
>
>
