cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 13:31:53 GMT
If you set up "configuration" with trust deciders and other security 
related stuff, you are fooled into thinking you are actually protecting 
the send to one endpoint, when in fact it's getting shipped off to a 
completely different endpoint than the one you configured.
If that's allowed to happen, then you have no assurance what is 
happening and you just might as well protect things down at a lower 
level with VPN stuff.

Cheers,
-Polar


Dan Diephouse wrote:
> I tend to agree with Polar that it is kind of weird. I thought the 
> idea was
> that a Conduit is supposed to be a Conduit to a particular endpoint, not
> many.
>
> BUT there is the practical issue of configuration. We may want to 
> configure
> our conduit based on:
> 1. The particular jax-ws client & the wsdl port it is talking to
> 2. The particular URL
> 3. Both 1 & 2.
>
> The problem with #1 is that you have to put in the logic in conduits 
> that we
> already have. The problem with #2 is that we can't have different clients
> talk to the same url with different settings.
>
> I guess we could go down the route of:
> - If a different EPR is specified create a new Conduit in the
> MessageSenderInterceptor
> - Apply the configuration to the new conduit like it would be applied 
> to the
> original conduit
>
> But wouldn't that be pretty much equivalent (at least for the HTTP case)?
>
> - Dan
>
> On 3/12/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: Polar Humenn [mailto:phumenn@iona.com]
>> > Sent: 12 March 2007 20:28
>> > To: cxf-dev@incubator.apache.org
>> > Subject: http: URLs and setepURL
>> >
>> > In the HttpConduit I have noticed that the "url" for the
>> > conduit is set up in the constructors from the EndpointInfo,
>> > or the EndpointReferenceType.
>> >
>> > However, it maybe totally overridden in send(Message) by the
>> > Message.ENDPOINT_ADDRESS on the message. What purpose does this have?
>>
>>
>> I'd imagine the purpose is to support the standard JAX-WS mechanism
>> whereby the application can explicitly control the target address by
>> setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on the request
>> context.
>>
>>
>> > Shouldn't this conduit ONLY be sending messages to the
>> > endpoint designated (configured) for it?
>>
>>
>> Not necessarily.
>>
>> The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to give
>> the client application the flexibility to override the target endpoint
>> address if necessary. For example the service may have migrated to a new
>> address, but the WSDL or annotated Java available to the client app may
>> be out-of-date.
>>
>>
>> > Furthermore, the code fragment in setupURL
>> >
>> >         String result = value != null ? value : url.toString();
>> >          if (null != pathInfo && !result.endWith(pathInfo)) {
>> >                 result = result + pathInfo;
>> >         }
>> >
>> > has a bit of a caveat in that you'd never be able to send a
>> > request to a location of  "http://somewhere.com/xx/xx",
>> > specified by a URL of "http://somwhere.com/xx" a
>> > Message.PATH_INFO property of "/xx".
>>
>>
>> If you think this is an important usage scenario, feel free to submit a
>> patch with a fix.
>>
>>
>> > Now some might say "why would you want to do that?" I know
>> > "xx" doesn't make sense to most, but what about,
>> >
>> >          "http://somewhere.com/path/to/parent/.."
>> >
>> > as a URL location built up from other things you might have
>> > dealt with, and you want to set a path from there to be "/.."
>> > Then you are in a completely different location than you want to be.
>> >
>> > Is there a specific "contract" are placed on
>> > Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this
>> > situation, or its it a bug?
>> >
>> > Cheers,
>> > -Polar
>> >
>> >
>>
>
>
>


Mime
View raw message