Here is what I think is the correct behavior: - If the method is POST and the parameters are not empty, then content should be ignored (as content and form post are mutually exclusive) and the request should be considered a form post. - Otherwise, if the content is not null and the method is not TRACE or CONNECT, then we use the content and the content type supplied by the caller. - The Host field from the caller should be reset by the encoder. - The User-Agent field from the caller should be reset by the encoder. - The Content-Type field from the caller is ignored and reset by the encoder if it is a form post (see first point). - The Content-Length field from the caller is ignored and reset by the encoder.
Rick's patch for GERONIMO-3839 looks great by the way, and it achieves some of these. I'll see if I can come up with a patch that addresses the content issue based on Rick's patch... Thanks, Sangjin On Feb 12, 2008 10:34 AM, Sangjin Lee <[EMAIL PROTECTED]> 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[]). > 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 > >
