You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by greenstar <jn...@gmail.com> on 2010/04/24 05:51:32 UTC
jetty:http component "mangles" x-www-form-urlencoded POST in
message:
When a POST arrives to an endpoint:
ie:
curl -d "x=1&y=2 http://localhost/foobar
The IN body is removed and the form params are moved to the message header.
How can I disable this feature? When this happens, I cannot "proxy" through
to another http endpoint that expects a POST of type
application/x-www-form-urlencoded unless I recreate the body myself.
(However, even still, recreating the body would be difficult because it's
hard to determine which headers where actually form params in the original
POST body and which were not because they aren't distinguished from the
other headers in any way).
This "feature" seems to be described
https://issues.apache.org/activemq/browse/CAMEL-1806 here . Perhaps I am
missing something, but is this feature really a good idea? When the request
is mangled in this way, I cannot pass this message through to another
service (proxy) because the body of the message is gone. I can perhaps see
pushing the form params into the headers while leaving the body intact, but
what is the rationale for removing the body?
If this feature was removed, one could always write a filter to convert POST
bodies to headers for type application/x-www-form-urlencoded. However, with
this feature implemented the way it is, it makes proxying POSTs of type
application/x-www-form-urlencoded practically impossible. Am I missing
something?
Thanks for your help.
(I am using Camel 2.2.0).
--
View this message in context: http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-tp28348176p28348176.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
Willem Jiang wrote:
> greenstar wrote:
>>
>>
>> willem.jiang wrote:
>>> I did some refactoring on current DefaultHttpBinding[1], now you can
>>> override the populateMessageHeader in your HttpBinding.
>>>
>>> [1] https://issues.apache.org/activemq/browse/CAMEL-2673
>>>
>>
>> Perhaps DefaultHttpBinding should be changed to leave
>> "application/x-www-form-urlencoded" POST bodies intact (of course it can
>> still propagate form params to the camel message headers). This would be
>> similar to the current querystring param behavior: these get
>> propagated to
>> the camel message, but they don't get stripped from the "original"
>> querystring. Any downsides to this? The upside is less intrusive
>> message
>> modifications which can be pretty destructive to proxying applications.
>
> I agree with you and will cache the InputSteam before calling the
> Request.getParameterNames().
>
> Willem
>
I committed a patch for it[1], please check out the last camel
2.3-SNAPSHOT for verification.
[1]https://issues.apache.org/activemq/browse/CAMEL-2679
Willem
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
greenstar wrote:
>
>
> willem.jiang wrote:
>> I did some refactoring on current DefaultHttpBinding[1], now you can
>> override the populateMessageHeader in your HttpBinding.
>>
>> [1] https://issues.apache.org/activemq/browse/CAMEL-2673
>>
>
> Perhaps DefaultHttpBinding should be changed to leave
> "application/x-www-form-urlencoded" POST bodies intact (of course it can
> still propagate form params to the camel message headers). This would be
> similar to the current querystring param behavior: these get propagated to
> the camel message, but they don't get stripped from the "original"
> querystring. Any downsides to this? The upside is less intrusive message
> modifications which can be pretty destructive to proxying applications.
I agree with you and will cache the InputSteam before calling the
Request.getParameterNames().
Willem
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by greenstar <jn...@gmail.com>.
willem.jiang wrote:
>
> I did some refactoring on current DefaultHttpBinding[1], now you can
> override the populateMessageHeader in your HttpBinding.
>
> [1] https://issues.apache.org/activemq/browse/CAMEL-2673
>
Perhaps DefaultHttpBinding should be changed to leave
"application/x-www-form-urlencoded" POST bodies intact (of course it can
still propagate form params to the camel message headers). This would be
similar to the current querystring param behavior: these get propagated to
the camel message, but they don't get stripped from the "original"
querystring. Any downsides to this? The upside is less intrusive message
modifications which can be pretty destructive to proxying applications.
--
View this message in context: http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-tp28348176p28367402.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
greenstar wrote:
>
> willem.jiang wrote:
>> 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.
>>
>
> In my particular case, I am doing various types of HTTP-level processing
> before it is eventually proxied. For example: I have several services
> behind camel: For each proxied service I do 500 error hiding and reporting,
> wiretapping for certain types of business operations, some CAS
> authentication, and 503 (Service Unavailable) detours among other things...
>
> Thanks for the suggestion though - camel-mina sounds great for tcp level
> proxying.
>
I did some refactoring on current DefaultHttpBinding[1], now you can
override the populateMessageHeader in your HttpBinding.
[1] https://issues.apache.org/activemq/browse/CAMEL-2673
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by greenstar <jn...@gmail.com>.
willem.jiang wrote:
>
> 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.
>
In my particular case, I am doing various types of HTTP-level processing
before it is eventually proxied. For example: I have several services
behind camel: For each proxied service I do 500 error hiding and reporting,
wiretapping for certain types of business operations, some CAS
authentication, and 503 (Service Unavailable) detours among other things...
Thanks for the suggestion though - camel-mina sounds great for tcp level
proxying.
--
View this message in context: http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-tp28348176p28360572.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
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.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
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.
I did some refactoring on current DefaultHttpBinding[1], now you can
override the populateMessageHeader in your HttpBinding to avoid putting
the form parameter into message header.
[1] https://issues.apache.org/activemq/browse/CAMEL-2673
Willem
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by greenstar <jn...@gmail.com>.
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.
--
View this message in context: http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-tp28348176p28359919.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
Thanks for your patch. I will review you path today and will keep you
posted.
Willem
greenstar wrote:
>
> willem.jiang wrote:
>> Here is a way for you to work around this issue by extending the
>> DefaultHttpBinding without calling the
>> HttpServletRequest.getParameterNames() if the method is POST , then you
>> set this binding into the JettyHttpComponent.
>>
>
> Thanks for the suggestion Willem. I've implemented this solution (and
> attached it to https://issues.apache.org/activemq/browse/CAMEL-1806
> CAMEL-1806 ). I'd appreciate it if you (and others) could review it and
> provide feedback. The solution still propagates the POST form params to the
> message headers, but preserves the body (so proxying still works).
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by greenstar <jn...@gmail.com>.
willem.jiang wrote:
>
> Here is a way for you to work around this issue by extending the
> DefaultHttpBinding without calling the
> HttpServletRequest.getParameterNames() if the method is POST , then you
> set this binding into the JettyHttpComponent.
>
Thanks for the suggestion Willem. I've implemented this solution (and
attached it to https://issues.apache.org/activemq/browse/CAMEL-1806
CAMEL-1806 ). I'd appreciate it if you (and others) could review it and
provide feedback. The solution still propagates the POST form params to the
message headers, but preserves the body (so proxying still works).
--
View this message in context: http://old.nabble.com/jetty%3Ahttp-component-%22mangles%22-x-www-form-urlencoded-POST-in-message%3A-tp28348176p28354331.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: jetty:http component "mangles" x-www-form-urlencoded POST in
message:
Posted by Willem Jiang <wi...@gmail.com>.
greenstar wrote:
> When a POST arrives to an endpoint:
>
> ie:
> curl -d "x=1&y=2 http://localhost/foobar
>
> The IN body is removed and the form params are moved to the message header.
> How can I disable this feature?
Current camel-jetty component doesn't support to disable this feature by
doing some simple configuration.
> When this happens, I cannot "proxy" through
> to another http endpoint that expects a POST of type
> application/x-www-form-urlencoded unless I recreate the body myself.
> (However, even still, recreating the body would be difficult because it's
> hard to determine which headers where actually form params in the original
> POST body and which were not because they aren't distinguished from the
> other headers in any way).
>
> This "feature" seems to be described
> https://issues.apache.org/activemq/browse/CAMEL-1806 here . Perhaps I am
> missing something, but is this feature really a good idea? When the request
> is mangled in this way, I cannot pass this message through to another
> service (proxy) because the body of the message is gone. I can perhaps see
> pushing the form params into the headers while leaving the body intact, but
> what is the rationale for removing the body?
When you call the HttpServletRequest.getParameterNames(), it will
consumer the body part if the content-type is
"application/x-www-form-urlencoded"
>
> If this feature was removed, one could always write a filter to convert POST
> bodies to headers for type application/x-www-form-urlencoded. However, with
> this feature implemented the way it is, it makes proxying POSTs of type
> application/x-www-form-urlencoded practically impossible. Am I missing
> something?
Using a filter could a way to do it, it will introduce other problem.
Because When we create the CamelServlet, we don't know if the endpoint
will be used as a proxy or not, it should be better to do it in
DefaultHttpBinding.
Here is a way for you to work around this issue by extending the
DefaultHttpBinding without calling the
HttpServletRequest.getParameterNames() if the method is POST , then you
set this binding into the JettyHttpComponent.
>
> Thanks for your help.
>
> (I am using Camel 2.2.0).
Willem