geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee" <sjl...@gmail.com>
Subject Re: [AsyncHttpClient] handling user-supplied request body (and content type)
Date Tue, 12 Feb 2008 18:57:01 GMT
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 <sjlee0@gmail.com> 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
>
>

Mime
View raw message