Thanks much for taking care of this Rick! Shall we move the bug to ASYNCWEB like the last time?
Regards, Sangjin On Feb 12, 2008 3:43 PM, Sangjin Lee <[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]> 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]>> 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 > > > > > > > > > > > > > > >
