Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Sangjin Lee]

No worries.  I'll work on creating a patch for asyncweb, and let you know.
Thanks,
Sangjin


On Feb 13, 2008 10:42 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:

> 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]
> > > 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]
> > 
> > > >> 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
> > > >
> > >
> > >
> >
> >
> >
>
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Rick McGuire]

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] 
> 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]

> >> 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
> >
>
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Sangjin Lee]

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]
> > > > 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
> > > >
> > >
> > >
> >
> >
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Sangjin Lee]

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]
> > > 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
> > >
> >
> >
>
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Rick McGuire]

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] 
> 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
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Sangjin Lee]

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...
Thanks,
Sangjin

On Feb 12, 2008 11:12 AM, Rick McGuire <[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
> >
>
>

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Rick McGuire]

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

Re: [AsyncHttpClient] handling user-supplied request body (and content type)

[Sangjin Lee]

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
>
>