|
|
You're in the
dotnet web services enhancements
group:WSE pipeline with no filters generates some SOAP headers
dotnet web services enhancements:
The only issue that you would potentially have is if any soap header is marked with the must understand attribute. WSE does add addressing headers for the simple reason that many of the WS-* specs that WSE implements use addressing headers. This is not mandatory. The filters dont generate the headers but its the serialization/deserialization mechanism of the WSE soap stack. HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com http://www.geniant.com [quoted text, click to view] > I am using IDE generated proxy with WebServicesClientProtocol as a > base > class (which means using WSE and its pipeline). > Before invoking web service I get Pipeline object from this proxy and > clear > all InputFilters collection. When I trace what is actually sent I > still see > Soap headers > enjected into message, for ex: wsa:To, wsa:Reply which sound to be > from > WS-Addressing if I am not mistaken. > Anyway the question: why does proxy class generate these headers when > no filters exist in the pipeline and "traditional" (with no soap > headers) payload is expected? > > Also this actually produces some interesting results: If I call Web > service on the server side which is also implemented with WSE but does > not use any filters it may throw an exception if requested URL does > not match wsa:To header value - and this all because base classes > derivd from WSE bases, rather then System.Web.Services ???????? > > Thankx, > Andrew
I am using IDE generated proxy with WebServicesClientProtocol as a base
class (which means using WSE and its pipeline). Before invoking web service I get Pipeline object from this proxy and clear all InputFilters collection. When I trace what is actually sent I still see Soap headers enjected into message, for ex: wsa:To, wsa:Reply which sound to be from WS-Addressing if I am not mistaken. Anyway the question: why does proxy class generate these headers when no filters exist in the pipeline and "traditional" (with no soap headers) payload is expected? Also this actually produces some interesting results: If I call Web service on the server side which is also implemented with WSE but does not use any filters it may throw an exception if requested URL does not match wsa:To header value - and this all because base classes derivd from WSE bases, rather then System.Web.Services ???????? Thankx, Andrew
Hello Andrew,
Don't use WSE if you dont need the WS-* spec as part of your soap stack HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com http://www.geniant.com [quoted text, click to view] > This does not make sence - why is that addressing headers should > always be > present when using WSE? > Why can't I use WSE and stay on a traditional (and standard) SOAP > stack? > Anyway, the real question now: is there any way to avoid > serialization/deserialization of these headers if I don't care to have > them when using WSE? > > Thanks, > Andrew > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:194513632418523340396816@msnews.microsoft.com... > >> Hello AVS, >> The only issue that you would potentially have is if any soap header >> is marked with the must understand attribute. WSE does add addressing > headers > >> for the simple reason that many of the WS-* specs that WSE >> implements use addressing headers. This is not mandatory. The filters >> dont generate the headers but its the serialization/deserialization >> mechanism of the WSE >> > soap > >> stack. >> >> HTH >> Regards, >> Dilip Krishnan >> MCAD, MCSD.net >> dkrishnan at geniant dot com >> http://www.geniant.com >>> I am using IDE generated proxy with WebServicesClientProtocol as a >>> base >>> class (which means using WSE and its pipeline). >>> Before invoking web service I get Pipeline object from this proxy >>> and >>> clear >>> all InputFilters collection. When I trace what is actually sent I >>> still see >>> Soap headers >>> enjected into message, for ex: wsa:To, wsa:Reply which sound to be >>> from >>> WS-Addressing if I am not mistaken. >>> Anyway the question: why does proxy class generate these headers >>> when >>> no filters exist in the pipeline and "traditional" (with no soap >>> headers) payload is expected? >>> Also this actually produces some interesting results: If I call Web >>> service on the server side which is also implemented with WSE but >>> does not use any filters it may throw an exception if requested URL >>> does not match wsa:To header value - and this all because base >>> classes derivd from WSE bases, rather then System.Web.Services >>> ???????? >>> >>> Thankx, >>> Andrew
How about not using WSE if you don't need any of its features?
-- --- Sven. [quoted text, click to view] "Andrew" <aslivker@digev.com> wrote in message news:#TCWkj9$EHA.1188@tk2msftngp13.phx.gbl... > This does not make sence - why is that addressing headers should always be > present when using WSE? > Why can't I use WSE and stay on a traditional (and standard) SOAP stack? > > Anyway, the real question now: is there any way to avoid > serialization/deserialization of these headers if I don't care to have them > when using WSE? > > Thanks, > Andrew > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:194513632418523340396816@msnews.microsoft.com... > > Hello AVS, > > The only issue that you would potentially have is if any soap header > > is marked with the must understand attribute. WSE does add addressing > headers > > for the simple reason that many of the WS-* specs that WSE implements use > > addressing headers. This is not mandatory. The filters dont generate the > > headers but its the serialization/deserialization mechanism of the WSE > soap > > stack. > > > > HTH > > Regards, > > Dilip Krishnan > > MCAD, MCSD.net > > dkrishnan at geniant dot com > > http://www.geniant.com > > > > > I am using IDE generated proxy with WebServicesClientProtocol as a > > > base > > > class (which means using WSE and its pipeline). > > > Before invoking web service I get Pipeline object from this proxy and > > > clear > > > all InputFilters collection. When I trace what is actually sent I > > > still see > > > Soap headers > > > enjected into message, for ex: wsa:To, wsa:Reply which sound to be > > > from > > > WS-Addressing if I am not mistaken. > > > Anyway the question: why does proxy class generate these headers when > > > no filters exist in the pipeline and "traditional" (with no soap > > > headers) payload is expected? > > > > > > Also this actually produces some interesting results: If I call Web > > > service on the server side which is also implemented with WSE but does > > > not use any filters it may throw an exception if requested URL does > > > not match wsa:To header value - and this all because base classes > > > derivd from WSE bases, rather then System.Web.Services ???????? > > > > > > Thankx, > > > Andrew > > > > > >
This does not make sence - why is that addressing headers should always be
present when using WSE? Why can't I use WSE and stay on a traditional (and standard) SOAP stack? Anyway, the real question now: is there any way to avoid serialization/deserialization of these headers if I don't care to have them when using WSE? Thanks, Andrew [quoted text, click to view] "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message news:194513632418523340396816@msnews.microsoft.com... > Hello AVS, > The only issue that you would potentially have is if any soap header > is marked with the must understand attribute. WSE does add addressing headers > for the simple reason that many of the WS-* specs that WSE implements use > addressing headers. This is not mandatory. The filters dont generate the > headers but its the serialization/deserialization mechanism of the WSE soap > stack. > > HTH > Regards, > Dilip Krishnan > MCAD, MCSD.net > dkrishnan at geniant dot com > http://www.geniant.com > > > I am using IDE generated proxy with WebServicesClientProtocol as a > > base > > class (which means using WSE and its pipeline). > > Before invoking web service I get Pipeline object from this proxy and > > clear > > all InputFilters collection. When I trace what is actually sent I > > still see > > Soap headers > > enjected into message, for ex: wsa:To, wsa:Reply which sound to be > > from > > WS-Addressing if I am not mistaken. > > Anyway the question: why does proxy class generate these headers when > > no filters exist in the pipeline and "traditional" (with no soap > > headers) payload is expected? > > > > Also this actually produces some interesting results: If I call Web > > service on the server side which is also implemented with WSE but does > > not use any filters it may throw an exception if requested URL does > > not match wsa:To header value - and this all because base classes > > derivd from WSE bases, rather then System.Web.Services ???????? > > > > Thankx, > > Andrew > >
That's the thing! - I need to use WSE for WS-Security, but I don't want to
deal with Addressing headers, just Security headers, because these addressing headers (wsa:To) specifically screws me up when I use WSE on top of my own Web Services infrastructure with multiple hops and I do not want to modify soap payload (meaning wsa:To) during my hops' processing. In other words my ultimate client send soap payload not where it is actually executed but though some hops. I would like to (and I should have been able) to twick only url-s , now I also have to twick soap headers (: [quoted text, click to view] "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message news:201330632419062782676720@msnews.microsoft.com... > Hello Andrew, > Don't use WSE if you dont need the WS-* spec as part of your soap stack > > HTH > Regards, > Dilip Krishnan > MCAD, MCSD.net > dkrishnan at geniant dot com > http://www.geniant.com > > > This does not make sence - why is that addressing headers should > > always be > > present when using WSE? > > Why can't I use WSE and stay on a traditional (and standard) SOAP > > stack? > > Anyway, the real question now: is there any way to avoid > > serialization/deserialization of these headers if I don't care to have > > them when using WSE? > > > > Thanks, > > Andrew > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > news:194513632418523340396816@msnews.microsoft.com... > > > >> Hello AVS, > >> The only issue that you would potentially have is if any soap header > >> is marked with the must understand attribute. WSE does add addressing > > headers > > > >> for the simple reason that many of the WS-* specs that WSE > >> implements use addressing headers. This is not mandatory. The filters > >> dont generate the headers but its the serialization/deserialization > >> mechanism of the WSE > >> > > soap > > > >> stack. > >> > >> HTH > >> Regards, > >> Dilip Krishnan > >> MCAD, MCSD.net > >> dkrishnan at geniant dot com > >> http://www.geniant.com > >>> I am using IDE generated proxy with WebServicesClientProtocol as a > >>> base > >>> class (which means using WSE and its pipeline). > >>> Before invoking web service I get Pipeline object from this proxy > >>> and > >>> clear > >>> all InputFilters collection. When I trace what is actually sent I > >>> still see > >>> Soap headers > >>> enjected into message, for ex: wsa:To, wsa:Reply which sound to be > >>> from > >>> WS-Addressing if I am not mistaken. > >>> Anyway the question: why does proxy class generate these headers > >>> when > >>> no filters exist in the pipeline and "traditional" (with no soap > >>> headers) payload is expected? > >>> Also this actually produces some interesting results: If I call Web > >>> service on the server side which is also implemented with WSE but > >>> does not use any filters it may throw an exception if requested URL > >>> does not match wsa:To header value - and this all because base > >>> classes derivd from WSE bases, rather then System.Web.Services > >>> ???????? > >>> > >>> Thankx, > >>> Andrew > >
Andrew,
I *think* I know what you are trying to get at. At the moment, I cannot answer directly the question how not to serialize the addressing headers while using WSE. However, I would think a "hack" can be done by writing a SOAPOutputFilter to hook into the message and remove the headers *manually*. I dont really know how that would affect the processing at the receiving end though. Will have to look into it later to see how I could help. On another note, the addressing headers should *not* be changed by any of your intermediaries during hop-processing as it can be signed. If your intermediaries are implemented using WSE and SOAPHTTPRouter as well, this shouldnt be a problem as it will just forward the requests to the next node or the ultimate receiver. It will not process the security headers that are not meant for itself. (actorless attribute or actor attribute = final destination). Having said that, your ultimate receiver should be expecting a message that has addressing headers wsa:To meant for the first routing or hop actor. This can be done by using the SOAPActor attribute on your Web Service. <SoapActor("http://localhost/dotnetproj/securesoapchain/Hop1/Router1.ashx"). ...> The good thing about that is the client *technically" doesnt have to know the address of the final destination. Technically, you shouldnt have to change your addressing headers. I would like to understand your concerns better. Is there is a reason for you doing it ? -- Thank you. Regards, William T (Softwaremaker) http://www.softwaremaker.net/blog ========================================= [quoted text, click to view] "Andrew" <aslivker@digev.com> wrote in message news:OZbysq#$EHA.1564@TK2MSFTNGP09.phx.gbl... > That's the thing! - I need to use WSE for WS-Security, but I don't want to > deal with Addressing headers, just Security headers, because these > addressing headers (wsa:To) specifically screws me up > when I use WSE on top of my own Web Services infrastructure with multiple > hops and I do not want to modify soap payload (meaning wsa:To) during my > hops' processing. In other words my ultimate client send soap payload not > where it is actually executed but though some hops. I would like to (and I > should have been able) to twick only url-s , now I also have to twick soap > headers (: > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:201330632419062782676720@msnews.microsoft.com... > > Hello Andrew, > > Don't use WSE if you dont need the WS-* spec as part of your soap > stack > > > > HTH > > Regards, > > Dilip Krishnan > > MCAD, MCSD.net > > dkrishnan at geniant dot com > > http://www.geniant.com > > > > > This does not make sence - why is that addressing headers should > > > always be > > > present when using WSE? > > > Why can't I use WSE and stay on a traditional (and standard) SOAP > > > stack? > > > Anyway, the real question now: is there any way to avoid > > > serialization/deserialization of these headers if I don't care to have > > > them when using WSE? > > > > > > Thanks, > > > Andrew > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > > news:194513632418523340396816@msnews.microsoft.com... > > > > > >> Hello AVS, > > >> The only issue that you would potentially have is if any soap header > > >> is marked with the must understand attribute. WSE does add addressing > > > headers > > > > > >> for the simple reason that many of the WS-* specs that WSE > > >> implements use addressing headers. This is not mandatory. The filters > > >> dont generate the headers but its the serialization/deserialization > > >> mechanism of the WSE > > >> > > > soap > > > > > >> stack. > > >> > > >> HTH > > >> Regards, > > >> Dilip Krishnan > > >> MCAD, MCSD.net > > >> dkrishnan at geniant dot com > > >> http://www.geniant.com > > >>> I am using IDE generated proxy with WebServicesClientProtocol as a > > >>> base > > >>> class (which means using WSE and its pipeline). > > >>> Before invoking web service I get Pipeline object from this proxy > > >>> and > > >>> clear > > >>> all InputFilters collection. When I trace what is actually sent I > > >>> still see > > >>> Soap headers > > >>> enjected into message, for ex: wsa:To, wsa:Reply which sound to be > > >>> from > > >>> WS-Addressing if I am not mistaken. > > >>> Anyway the question: why does proxy class generate these headers > > >>> when > > >>> no filters exist in the pipeline and "traditional" (with no soap > > >>> headers) payload is expected? > > >>> Also this actually produces some interesting results: If I call Web > > >>> service on the server side which is also implemented with WSE but > > >>> does not use any filters it may throw an exception if requested URL > > >>> does not match wsa:To header value - and this all because base > > >>> classes derivd from WSE bases, rather then System.Web.Services > > >>> ???????? > > >>> > > >>> Thankx, > > >>> Andrew > > > > > >
Andrew,
I *think* I know what you are trying to get at. At the moment, I cannot answer directly the question how not to serialize the addressing headers while using WSE. However, I would think a "hack" can be done by writing a SOAPOutputFilter to hook into the message and remove the headers *manually*. I dont really know how that would affect the processing at the receiving end though. Will have to look into it later to see how I could help. On another note, the addressing headers should *not* be changed by any of your intermediaries during hop-processing as it can be signed. If your intermediaries are implemented using WSE and SOAPHTTPRouter as well, this shouldnt be a problem as it will just forward the requests to the next node or the ultimate receiver. It will not process the security headers that are not meant for itself. (actorless attribute or actor attribute = final destination). Having said that, your ultimate receiver should be expecting a message that has addressing headers wsa:To meant for the first routing or hop actor. This can be done by using the SOAPActor attribute on your Web Service. <SoapActor("http://localhost/dotnetproj/securesoapchain/Hop1/Router1.ashx"). ...> The good thing about that is the client *technically" doesnt have to know the address of the final destination. Technically, you shouldnt have to change your addressing headers. I would like to understand your concerns better. Is there is a reason for you doing it ? -- Thank you. Regards, William T (Softwaremaker) http://www.softwaremaker.net/blog ========================================= [quoted text, click to view] "Andrew" <aslivker@digev.com> wrote in message news:OZbysq#$EHA.1564@TK2MSFTNGP09.phx.gbl... > That's the thing! - I need to use WSE for WS-Security, but I don't want to > deal with Addressing headers, just Security headers, because these > addressing headers (wsa:To) specifically screws me up > when I use WSE on top of my own Web Services infrastructure with multiple > hops and I do not want to modify soap payload (meaning wsa:To) during my > hops' processing. In other words my ultimate client send soap payload not > where it is actually executed but though some hops. I would like to (and I > should have been able) to twick only url-s , now I also have to twick soap > headers (: > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:201330632419062782676720@msnews.microsoft.com... > > Hello Andrew, > > Don't use WSE if you dont need the WS-* spec as part of your soap > stack > > > > HTH > > Regards, > > Dilip Krishnan > > MCAD, MCSD.net > > dkrishnan at geniant dot com > > http://www.geniant.com > > > > > This does not make sence - why is that addressing headers should > > > always be > > > present when using WSE? > > > Why can't I use WSE and stay on a traditional (and standard) SOAP > > > stack? > > > Anyway, the real question now: is there any way to avoid > > > serialization/deserialization of these headers if I don't care to have > > > them when using WSE? > > > > > > Thanks, > > > Andrew > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > > news:194513632418523340396816@msnews.microsoft.com... > > > > > >> Hello AVS, > > >> The only issue that you would potentially have is if any soap header > > >> is marked with the must understand attribute. WSE does add addressing > > > headers > > > > > >> for the simple reason that many of the WS-* specs that WSE > > >> implements use addressing headers. This is not mandatory. The filters > > >> dont generate the headers but its the serialization/deserialization > > >> mechanism of the WSE > > >> > > > soap > > > > > >> stack. > > >> > > >> HTH > > >> Regards, > > >> Dilip Krishnan > > >> MCAD, MCSD.net > > >> dkrishnan at geniant dot com > > >> http://www.geniant.com > > >>> I am using IDE generated proxy with WebServicesClientProtocol as a > > >>> base > > >>> class (which means using WSE and its pipeline). > > >>> Before invoking web service I get Pipeline object from this proxy > > >>> and > > >>> clear > > >>> all InputFilters collection. When I trace what is actually sent I > > >>> still see > > >>> Soap headers > > >>> enjected into message, for ex: wsa:To, wsa:Reply which sound to be > > >>> from > > >>> WS-Addressing if I am not mistaken. > > >>> Anyway the question: why does proxy class generate these headers > > >>> when > > >>> no filters exist in the pipeline and "traditional" (with no soap > > >>> headers) payload is expected? > > >>> Also this actually produces some interesting results: If I call Web > > >>> service on the server side which is also implemented with WSE but > > >>> does not use any filters it may throw an exception if requested URL > > >>> does not match wsa:To header value - and this all because base > > >>> classes derivd from WSE bases, rather then System.Web.Services > > >>> ???????? > > >>> > > >>> Thankx, > > >>> Andrew > > > > > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |