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 <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Polar Humenn [mailto:[EMAIL PROTECTED]
> Sent: 12 March 2007 20:28
> To: [email protected]
> 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
>
>
