Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.212.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=bDyaKOobNyKqAGuBvb4RQUnttkvH9czDalZb/qOMdkYLbZQ0ISMA0BbPU/TJRl71RT
         rcKgKvuvzwl8R2j/OuBE/rmyTTacbOqypEUsOT2y1C7eP4RJTWy+CdbwnQqIl9lRGm3O
         lmCJgTFrP+IUzy1AbHZt06IMY4fidFoOigwno=
Message-ID: <4BD4EF41.80509@gmail.com>
Date: Mon, 26 Apr 2010 09:41:21 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: jetty:http component "mangles" x-www-form-urlencoded POST in
 message:
References: <28348176.post@talk.nabble.com> <4BD29B76.8080909@gmail.com>
 <28354331.post@talk.nabble.com> <4BD4DB14.6040506@gmail.com>
 <28359919.post@talk.nabble.com>
In-Reply-To: <28359919.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I just have a quick thought, how about using camel-mina component to do 
the http proxy. In this way, it just do the tcp layer work and will not 
get touch with headers and body.

Willem

greenstar wrote:
> 
> willem.jiang wrote:
>> Thanks for your patch. I will review you path today and will keep you 
>> posted.
>>
> 
> Thanks.
> 
> I wonder if we can go further and provide more robust features/options for
> when the http endpoints are used for "proxying".  For example, it would be
> nice if the form params (either from the POST body or the query string)
> where moved to the headers in such a way as to able to filter them out
> before they are proxied out to the http destination (eg: say prefixed with
> X-Camel-FormParam-*).  In theory, a query param could cause problems when
> it's presented to the destination as a header as well (which wasn't the
> destination services intention).  For example, what if there is a query
> param called "Expires"?  Currently, this will end up in the HTTP request
> headers and almost certainly cause problems.