| Groups | Blog | Home |
dotnet web services enhancements : URI in Policy EndPoint Case Sensitive?
A client and I worked for 2 days on a WSE issue where the URI specified in
the policy was all lowercase. The final soap exception being dealt with before we got it running was that the current policy did not match the original policy. The client was making the call to the secured service with a camel cased URI, and this was apparently causing an issue. The client and server were using 2 way encryption and signing as well as a secure channel. After they made the query string all lower case, to match what was in the policy cache config, it all worked. If you actually used the MSF Design Process, you could classify this issue as being undocumented, with low visibility and having a very severe impact. Is this facet of the policy documented in the help somewhere? Why would case of the URI have anything to do with anything with regards to signed and encryped data?
Hi,
Could you please provide a little detail on what sort of URI's that you are dealing with? Could you perhaps give an example of the URI in the policy file, versus the URI that you are actually sending the request to? Thanks, Sidd [MSFT] [quoted text, click to view] "DevilDog74" <cedricb@youcanthaveit.com> wrote in message news:OU6CF4NBFHA.2392@TK2MSFTNGP14.phx.gbl... > A client and I worked for 2 days on a WSE issue where the URI specified in > the policy was all lowercase. The final soap exception being dealt with > before we got it running was that the current policy did not match the > original policy. > > The client was making the call to the secured service with a camel cased > URI, and this was apparently causing an issue. > > The client and server were using 2 way encryption and signing as well as a > secure channel. After they made the query string all lower case, to match > what was in the policy cache config, it all worked. > > If you actually used the MSF Design Process, you could classify this issue > as being undocumented, with low visibility and having a very severe impact. > > Is this facet of the policy documented in the help somewhere? Why would > case of the URI have anything to do with anything with regards to signed and > encryped data? > >
Hello DevilDog74,
Yes it is case sensitive and it certainly needs to be addressed IMO HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com http://www.geniant.com [quoted text, click to view] > A client and I worked for 2 days on a WSE issue where the URI > specified in the policy was all lowercase. The final soap exception > being dealt with before we got it running was that the current policy > did not match the original policy. > > The client was making the call to the secured service with a camel > cased URI, and this was apparently causing an issue. > > The client and server were using 2 way encryption and signing as well > as a secure channel. After they made the query string all lower case, > to match what was in the policy cache config, it all worked. > > If you actually used the MSF Design Process, you could classify this > issue as being undocumented, with low visibility and having a very > severe impact. > > Is this facet of the policy documented in the help somewhere? Why > would case of the URI have anything to do with anything with regards > to signed and encryped data? >
Hi Dilip,
I do not believe the endpoint uri specified in the policy file is case sensitive. Could you please give me an example of this as this needs to be investigated ASAP. In you response, if you could let me know if you are using ASMX, or soap.tcp, that would be very helpful as well. Thanks Sidd [MSFT]. [quoted text, click to view] "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message news:232955632424973340264240@msnews.microsoft.com... > Hello DevilDog74, > Yes it is case sensitive and it certainly needs to be addressed IMO > HTH > Regards, > Dilip Krishnan > MCAD, MCSD.net > dkrishnan at geniant dot com > http://www.geniant.com > > > A client and I worked for 2 days on a WSE issue where the URI > > specified in the policy was all lowercase. The final soap exception > > being dealt with before we got it running was that the current policy > > did not match the original policy. > > > > The client was making the call to the secured service with a camel > > cased URI, and this was apparently causing an issue. > > > > The client and server were using 2 way encryption and signing as well > > as a secure channel. After they made the query string all lower case, > > to match what was in the policy cache config, it all worked. > > > > If you actually used the MSF Design Process, you could classify this > > issue as being undocumented, with low visibility and having a very > > severe impact. > > > > Is this facet of the policy documented in the help somewhere? Why > > would case of the URI have anything to do with anything with regards > > to signed and encryped data? > > > >
[quoted text, click to view] "Sidd" wrote:
> Hi Dilip, > > I do not believe the endpoint uri specified in the policy file is case > sensitive. Could you please give me an example of this as this needs to be > investigated ASAP. > > In you response, if you could let me know if you are using ASMX, or > soap.tcp, that would be very helpful as well. > > Thanks > > Sidd [MSFT]. > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:232955632424973340264240@msnews.microsoft.com... > > Hello DevilDog74, > > Yes it is case sensitive and it certainly needs to be addressed IMO > > HTH > > Regards, > > Dilip Krishnan > > MCAD, MCSD.net > > dkrishnan at geniant dot com > > http://www.geniant.com > > > > > A client and I worked for 2 days on a WSE issue where the URI > > > specified in the policy was all lowercase. The final soap exception > > > being dealt with before we got it running was that the current policy > > > did not match the original policy. > > > > > > The client was making the call to the secured service with a camel > > > cased URI, and this was apparently causing an issue. > > > > > > The client and server were using 2 way encryption and signing as well > > > as a secure channel. After they made the query string all lower case, > > > to match what was in the policy cache config, it all worked. > > > > > > If you actually used the MSF Design Process, you could classify this > > > issue as being undocumented, with low visibility and having a very > > > severe impact. > > > > > > Is this facet of the policy documented in the help somewhere? Why > > > would case of the URI have anything to do with anything with regards > > > to signed and encryped data? > > > > > > > > >
The URIs provided in this scenario are not real, but demonstrate what I am
talking about, so please bear with me. We have a service hosted in IIS called myservice.asmx. The server is configured using the policy tool, it uses x509 and the wsdl can be found at http://www.somedomain.com/webservices/myservice.asmx. The service is set up to use a secure channel, plus 2 way signing and encryption. Using the VS.NET 2003 IDE, the client obtains a direct web reference to the wsdl. In the Add Web Reference tool for the IDE, the developer enters http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is retreived and the reference is created in the IDE, along with the proxy, etc etc. The url entered into the ide is camel cased. The developer then configures the cleint to use WSE2, using the WSE IDE tool. They configure their policy using the WSE policy addin. In their policy, when they add their endpoint name, they dont use the <DefaultEndpoint> they enter http://www.somedomain.com/webservices/myservice.asmx and configure their policy to be a client application, using s channel, with 2 way x509 signing and encryption. The developer builds and runs the client application and should receive a nice undocumented WSE policy verification error stating something along the lines that the current endpoint doesnt match the policy that it was mapped to. [quoted text, click to view] "Sidd" wrote:
> Hi Dilip, > > I do not believe the endpoint uri specified in the policy file is case > sensitive. Could you please give me an example of this as this needs to be > investigated ASAP. > > In you response, if you could let me know if you are using ASMX, or > soap.tcp, that would be very helpful as well. > > Thanks > > Sidd [MSFT]. > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > news:232955632424973340264240@msnews.microsoft.com... > > Hello DevilDog74, > > Yes it is case sensitive and it certainly needs to be addressed IMO > > HTH > > Regards, > > Dilip Krishnan > > MCAD, MCSD.net > > dkrishnan at geniant dot com > > http://www.geniant.com > > > > > A client and I worked for 2 days on a WSE issue where the URI > > > specified in the policy was all lowercase. The final soap exception > > > being dealt with before we got it running was that the current policy > > > did not match the original policy. > > > > > > The client was making the call to the secured service with a camel > > > cased URI, and this was apparently causing an issue. > > > > > > The client and server were using 2 way encryption and signing as well > > > as a secure channel. After they made the query string all lower case, > > > to match what was in the policy cache config, it all worked. > > > > > > If you actually used the MSF Design Process, you could classify this > > > issue as being undocumented, with low visibility and having a very > > > severe impact. > > > > > > Is this facet of the policy documented in the help somewhere? Why > > > would case of the URI have anything to do with anything with regards > > > to signed and encryped data? > > > > > > > > >
Hi,
I don't seem to be able to repro this. I have tried all sorts of casing possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate it if you could send me a small repro, or even if I could send you a repro and let me know what I am doing wrong. Your input on this is very much appreciated. Thanks, Sidd [MSFT] [quoted text, click to view] "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > The URIs provided in this scenario are not real, but demonstrate what I am > talking about, so please bear with me. > > We have a service hosted in IIS called myservice.asmx. > > The server is configured using the policy tool, it uses x509 and the wsdl > can be found at http://www.somedomain.com/webservices/myservice.asmx. The > service is set up to use a secure channel, plus 2 way signing and encryption. > > Using the VS.NET 2003 IDE, the client obtains a direct web reference to the > wsdl. In the Add Web Reference tool for the IDE, the developer enters > http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is retreived > and the reference is created in the IDE, along with the proxy, etc etc. The > url entered into the ide is camel cased. > > The developer then configures the cleint to use WSE2, using the WSE IDE > tool. They configure their policy using the WSE policy addin. In their > policy, when they add their endpoint name, they dont use the > <DefaultEndpoint> they enter > http://www.somedomain.com/webservices/myservice.asmx and configure their > policy to be a client application, using s channel, with 2 way x509 signing > and encryption. The developer builds and runs the client application and > should receive a nice undocumented WSE policy verification error stating > something along the lines that the current endpoint doesnt match the policy > that it was mapped to. > > "Sidd" wrote: > > > Hi Dilip, > > > > I do not believe the endpoint uri specified in the policy file is case > > sensitive. Could you please give me an example of this as this needs to be > > investigated ASAP. > > > > In you response, if you could let me know if you are using ASMX, or > > soap.tcp, that would be very helpful as well. > > > > Thanks > > > > Sidd [MSFT]. > > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > news:232955632424973340264240@msnews.microsoft.com... > > > Hello DevilDog74, > > > Yes it is case sensitive and it certainly needs to be addressed IMO > > > HTH > > > Regards, > > > Dilip Krishnan > > > MCAD, MCSD.net > > > dkrishnan at geniant dot com > > > http://www.geniant.com > > > > > > > A client and I worked for 2 days on a WSE issue where the URI > > > > specified in the policy was all lowercase. The final soap exception > > > > being dealt with before we got it running was that the current policy > > > > did not match the original policy. > > > > > > > > The client was making the call to the secured service with a camel > > > > cased URI, and this was apparently causing an issue. > > > > > > > > The client and server were using 2 way encryption and signing as well > > > > as a secure channel. After they made the query string all lower case, > > > > to match what was in the policy cache config, it all worked. > > > > > > > > If you actually used the MSF Design Process, you could classify this > > > > issue as being undocumented, with low visibility and having a very > > > > severe impact. > > > > > > > > Is this facet of the policy documented in the help somewhere? Why > > > > would case of the URI have anything to do with anything with regards > > > > to signed and encryped data? > > > > > > > > > > > > > > > >
Did you try making the URI dynamic and specifying the uri in the web .config
instead of the proxy? In any case, both the client and the server are on WSE2SP2. using default endpoint in the policy is not feasablee because why shoud we need to maintain 3 policy files that essentially have the same information in them except for where the service lives? The reason we use the named endpoint is because in our real scenario, I have dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, all of which have the same policy requirements. [quoted text, click to view] "Softwaremaker" wrote:
> I recalled a similar post a few months ago which [Lucien] and [Hervey] > replied that: > > Quote: URI's are treated case sensitive as defined in specifications/RFC > (except for the host name part). Arguably this is a bug in IIS and this is > 'fixed' in WSE. You could use default endpoint with action string URI's > instead (if that would fit into your scenario). > > Quote: This is a known bug that is fixed and will be in the next release. > The action value is to be treated as is (case sensitive) per WS-Addressing > spec. > I would though recommend against using upper case in host name part. > > -- > Thank you. > > Regards, > William T (Softwaremaker) > http://www.softwaremaker.net/blog > ========================================= > > > "Sidd" <ElCid@hotmail.com> wrote in message > news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > > Hi, > > > > I don't seem to be able to repro this. I have tried all sorts of > casing > > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate > > it if you could send me a small repro, or even if I could send you a repro > > and let me know what I am doing wrong. > > > > Your input on this is very much appreciated. > > > > Thanks, > > > > Sidd [MSFT] > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > > news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > > > The URIs provided in this scenario are not real, but demonstrate what I > am > > > talking about, so please bear with me. > > > > > > We have a service hosted in IIS called myservice.asmx. > > > > > > The server is configured using the policy tool, it uses x509 and the > wsdl > > > can be found at http://www.somedomain.com/webservices/myservice.asmx. > The > > > service is set up to use a secure channel, plus 2 way signing and > > encryption. > > > > > > Using the VS.NET 2003 IDE, the client obtains a direct web reference to > > the > > > wsdl. In the Add Web Reference tool for the IDE, the developer enters > > > http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is > > retreived > > > and the reference is created in the IDE, along with the proxy, etc etc. > > The > > > url entered into the ide is camel cased. > > > > > > The developer then configures the cleint to use WSE2, using the WSE IDE > > > tool. They configure their policy using the WSE policy addin. In their > > > policy, when they add their endpoint name, they dont use the > > > <DefaultEndpoint> they enter > > > http://www.somedomain.com/webservices/myservice.asmx and configure their > > > policy to be a client application, using s channel, with 2 way x509 > > signing > > > and encryption. The developer builds and runs the client application > and > > > should receive a nice undocumented WSE policy verification error stating > > > something along the lines that the current endpoint doesnt match the > > policy > > > that it was mapped to. > > > > > > "Sidd" wrote: > > > > > > > Hi Dilip, > > > > > > > > I do not believe the endpoint uri specified in the policy file is > > case > > > > sensitive. Could you please give me an example of this as this needs > to > > be > > > > investigated ASAP. > > > > > > > > In you response, if you could let me know if you are using ASMX, > or > > > > soap.tcp, that would be very helpful as well. > > > > > > > > Thanks > > > > > > > > Sidd [MSFT]. > > > > > > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > > > news:232955632424973340264240@msnews.microsoft.com... > > > > > Hello DevilDog74, > > > > > Yes it is case sensitive and it certainly needs to be addressed > > IMO > > > > > HTH > > > > > Regards, > > > > > Dilip Krishnan > > > > > MCAD, MCSD.net > > > > > dkrishnan at geniant dot com > > > > > http://www.geniant.com > > > > > > > > > > > A client and I worked for 2 days on a WSE issue where the URI > > > > > > specified in the policy was all lowercase. The final soap > exception > > > > > > being dealt with before we got it running was that the current > > policy > > > > > > did not match the original policy. > > > > > > > > > > > > The client was making the call to the secured service with a camel > > > > > > cased URI, and this was apparently causing an issue. > > > > > > > > > > > > The client and server were using 2 way encryption and signing as > > well > > > > > > as a secure channel. After they made the query string all lower > > case, > > > > > > to match what was in the policy cache config, it all worked. > > > > > > > > > > > > If you actually used the MSF Design Process, you could classify > this > > > > > > issue as being undocumented, with low visibility and having a very > > > > > > severe impact. > > > > > > > > > > > > Is this facet of the policy documented in the help somewhere? Why > > > > > > would case of the URI have anything to do with anything with > regards > > > > > > to signed and encryped data? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
So, I was able to repro this. In the ide change the URL Behavior from static
to dynamic. This action modifies the web.config file and modifies the constructor of the proxy. In my poliy the endpoint is all lower case. In my web.config, for the first test using SoftwareMakers post, I made the first letter of the host name uppercase. This test returned the proper results. In the second test, I made the first letter of evey word not in the host name uppercase and re-ran the test. I received the exception listed below, so it is cse sensitive, and my point is that doesnt seem to be documented and costs my organization a lot of time and money and now we have the client asking if we should event use WSE over something that is so silly compared to what the end result is. From the clients perspective, they cannot see the fact that their data is signed and encrypted and communicating over a secure channel. All the client sees is that their web services arent working and they are out 2 days of development. System.Web.Services.Protocols.SoapHeaderException: Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The message does not conform to the policy it was mapped to. at Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpression(PolicyExpression expression, SoapEnvelope message, EndpointReference endpoint, String action, Uri requestEndpoint) at Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope message) at Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage(SoapEnvelope envelope) at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) at Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapServerMessage message) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at WebServiceWse.myCourseList(String strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 [quoted text, click to view] "DevilDog74" wrote:
> Did you try making the URI dynamic and specifying the uri in the web .config > instead of the proxy? > > In any case, both the client and the server are on WSE2SP2. > > using default endpoint in the policy is not feasablee because why shoud we > need to maintain 3 policy files that essentially have the same information in > them except for where the service lives? > > The reason we use the named endpoint is because in our real scenario, I have > dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, all of > which have the same policy requirements. > > "Softwaremaker" wrote: > > > I recalled a similar post a few months ago which [Lucien] and [Hervey] > > replied that: > > > > Quote: URI's are treated case sensitive as defined in specifications/RFC > > (except for the host name part). Arguably this is a bug in IIS and this is > > 'fixed' in WSE. You could use default endpoint with action string URI's > > instead (if that would fit into your scenario). > > > > Quote: This is a known bug that is fixed and will be in the next release. > > The action value is to be treated as is (case sensitive) per WS-Addressing > > spec. > > I would though recommend against using upper case in host name part. > > > > -- > > Thank you. > > > > Regards, > > William T (Softwaremaker) > > http://www.softwaremaker.net/blog > > ========================================= > > > > > > "Sidd" <ElCid@hotmail.com> wrote in message > > news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > > > Hi, > > > > > > I don't seem to be able to repro this. I have tried all sorts of > > casing > > > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate > > > it if you could send me a small repro, or even if I could send you a repro > > > and let me know what I am doing wrong. > > > > > > Your input on this is very much appreciated. > > > > > > Thanks, > > > > > > Sidd [MSFT] > > > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > > > news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > > > > The URIs provided in this scenario are not real, but demonstrate what I > > am > > > > talking about, so please bear with me. > > > > > > > > We have a service hosted in IIS called myservice.asmx. > > > > > > > > The server is configured using the policy tool, it uses x509 and the > > wsdl > > > > can be found at http://www.somedomain.com/webservices/myservice.asmx. > > The > > > > service is set up to use a secure channel, plus 2 way signing and > > > encryption. > > > > > > > > Using the VS.NET 2003 IDE, the client obtains a direct web reference to > > > the > > > > wsdl. In the Add Web Reference tool for the IDE, the developer enters > > > > http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is > > > retreived > > > > and the reference is created in the IDE, along with the proxy, etc etc. > > > The > > > > url entered into the ide is camel cased. > > > > > > > > The developer then configures the cleint to use WSE2, using the WSE IDE > > > > tool. They configure their policy using the WSE policy addin. In their > > > > policy, when they add their endpoint name, they dont use the > > > > <DefaultEndpoint> they enter > > > > http://www.somedomain.com/webservices/myservice.asmx and configure their > > > > policy to be a client application, using s channel, with 2 way x509 > > > signing > > > > and encryption. The developer builds and runs the client application > > and > > > > should receive a nice undocumented WSE policy verification error stating > > > > something along the lines that the current endpoint doesnt match the > > > policy > > > > that it was mapped to. > > > > > > > > "Sidd" wrote: > > > > > > > > > Hi Dilip, > > > > > > > > > > I do not believe the endpoint uri specified in the policy file is > > > case > > > > > sensitive. Could you please give me an example of this as this needs > > to > > > be > > > > > investigated ASAP. > > > > > > > > > > In you response, if you could let me know if you are using ASMX, > > or > > > > > soap.tcp, that would be very helpful as well. > > > > > > > > > > Thanks > > > > > > > > > > Sidd [MSFT]. > > > > > > > > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > > > > news:232955632424973340264240@msnews.microsoft.com... > > > > > > Hello DevilDog74, > > > > > > Yes it is case sensitive and it certainly needs to be addressed > > > IMO > > > > > > HTH
Softwaremake, I actually gave you misinformation. The policy requirements
are not the same on all 3 services. In the production1.somedomain.com, the private key is a private key provided by a "Real" thawte ssl certficate, where as with the dev1 and qc1 policy, the certificate being used is issued by our development certificate server. [quoted text, click to view] "DevilDog74" wrote:
> So, I was able to repro this. In the ide change the URL Behavior from static > to dynamic. This action modifies the web.config file and modifies the > constructor of the proxy. > > In my poliy the endpoint is all lower case. In my web.config, for the > first test using SoftwareMakers post, I made the first letter of the host > name uppercase. This test returned the proper results. > > In the second test, I made the first letter of evey word not in the host > name uppercase and re-ran the test. I received the exception listed below, > so it is cse sensitive, and my point is that doesnt seem to be documented and > costs my organization a lot of time and money and now we have the client > asking if we should event use WSE over something that is so silly compared to > what the end result is. > > From the clients perspective, they cannot see the fact that their data is > signed and encrypted and communicating over a secure channel. All the client > sees is that their web services arent working and they are out 2 days of > development. > > System.Web.Services.Protocols.SoapHeaderException: > Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The > message does not conform to the policy it was mapped to. at > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpression(PolicyExpression > expression, SoapEnvelope message, EndpointReference endpoint, String action, > Uri requestEndpoint) at > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope > message) at > Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage(SoapEnvelope > envelope) at > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) > at > Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapServerMessage > message) at > System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage > message, WebResponse response, Stream responseStream, Boolean asyncCall) at > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > methodName, Object[] parameters) at WebServiceWse.myCourseList(String > strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web > references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at > eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in > c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 > > "DevilDog74" wrote: > > > Did you try making the URI dynamic and specifying the uri in the web .config > > instead of the proxy? > > > > In any case, both the client and the server are on WSE2SP2. > > > > using default endpoint in the policy is not feasablee because why shoud we > > need to maintain 3 policy files that essentially have the same information in > > them except for where the service lives? > > > > The reason we use the named endpoint is because in our real scenario, I have > > dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, all of > > which have the same policy requirements. > > > > "Softwaremaker" wrote: > > > > > I recalled a similar post a few months ago which [Lucien] and [Hervey] > > > replied that: > > > > > > Quote: URI's are treated case sensitive as defined in specifications/RFC > > > (except for the host name part). Arguably this is a bug in IIS and this is > > > 'fixed' in WSE. You could use default endpoint with action string URI's > > > instead (if that would fit into your scenario). > > > > > > Quote: This is a known bug that is fixed and will be in the next release. > > > The action value is to be treated as is (case sensitive) per WS-Addressing > > > spec. > > > I would though recommend against using upper case in host name part. > > > > > > -- > > > Thank you. > > > > > > Regards, > > > William T (Softwaremaker) > > > http://www.softwaremaker.net/blog > > > ========================================= > > > > > > > > > "Sidd" <ElCid@hotmail.com> wrote in message > > > news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > > > > Hi, > > > > > > > > I don't seem to be able to repro this. I have tried all sorts of > > > casing > > > > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate > > > > it if you could send me a small repro, or even if I could send you a repro > > > > and let me know what I am doing wrong. > > > > > > > > Your input on this is very much appreciated. > > > > > > > > Thanks, > > > > > > > > Sidd [MSFT] > > > > > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > > > > news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > > > > > The URIs provided in this scenario are not real, but demonstrate what I > > > am > > > > > talking about, so please bear with me. > > > > > > > > > > We have a service hosted in IIS called myservice.asmx. > > > > > > > > > > The server is configured using the policy tool, it uses x509 and the > > > wsdl > > > > > can be found at http://www.somedomain.com/webservices/myservice.asmx. > > > The > > > > > service is set up to use a secure channel, plus 2 way signing and > > > > encryption. > > > > > > > > > > Using the VS.NET 2003 IDE, the client obtains a direct web reference to > > > > the > > > > > wsdl. In the Add Web Reference tool for the IDE, the developer enters > > > > > http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is > > > > retreived > > > > > and the reference is created in the IDE, along with the proxy, etc etc. > > > > The > > > > > url entered into the ide is camel cased. > > > > > > > > > > The developer then configures the cleint to use WSE2, using the WSE IDE > > > > > tool. They configure their policy using the WSE policy addin. In their > > > > > policy, when they add their endpoint name, they dont use the > > > > > <DefaultEndpoint> they enter > > > > > http://www.somedomain.com/webservices/myservice.asmx and configure their > > > > > policy to be a client application, using s channel, with 2 way x509 > > > > signing > > > > > and encryption. The developer builds and runs the client application > > > and > > > > > should receive a nice undocumented WSE policy verification error stating > > > > > something along the lines that the current endpoint doesnt match the > > > > policy > > > > > that it was mapped to. > > > > > > > > > > "Sidd" wrote: > > > > > > > > > > > Hi Dilip, > > > > > >
I recalled a similar post a few months ago which [Lucien] and [Hervey]
replied that: Quote: URI's are treated case sensitive as defined in specifications/RFC (except for the host name part). Arguably this is a bug in IIS and this is 'fixed' in WSE. You could use default endpoint with action string URI's instead (if that would fit into your scenario). Quote: This is a known bug that is fixed and will be in the next release. The action value is to be treated as is (case sensitive) per WS-Addressing spec. I would though recommend against using upper case in host name part. -- Thank you. Regards, William T (Softwaremaker) http://www.softwaremaker.net/blog ========================================= [quoted text, click to view] "Sidd" <ElCid@hotmail.com> wrote in message news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > Hi, > > I don't seem to be able to repro this. I have tried all sorts of casing > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate > it if you could send me a small repro, or even if I could send you a repro > and let me know what I am doing wrong. > > Your input on this is very much appreciated. > > Thanks, > > Sidd [MSFT] > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > > The URIs provided in this scenario are not real, but demonstrate what I am > > talking about, so please bear with me. > > > > We have a service hosted in IIS called myservice.asmx. > > > > The server is configured using the policy tool, it uses x509 and the wsdl > > can be found at http://www.somedomain.com/webservices/myservice.asmx. The > > service is set up to use a secure channel, plus 2 way signing and > encryption. > > > > Using the VS.NET 2003 IDE, the client obtains a direct web reference to > the > > wsdl. In the Add Web Reference tool for the IDE, the developer enters > > http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is > retreived > > and the reference is created in the IDE, along with the proxy, etc etc. > The > > url entered into the ide is camel cased. > > > > The developer then configures the cleint to use WSE2, using the WSE IDE > > tool. They configure their policy using the WSE policy addin. In their > > policy, when they add their endpoint name, they dont use the > > <DefaultEndpoint> they enter > > http://www.somedomain.com/webservices/myservice.asmx and configure their > > policy to be a client application, using s channel, with 2 way x509 > signing > > and encryption. The developer builds and runs the client application and > > should receive a nice undocumented WSE policy verification error stating > > something along the lines that the current endpoint doesnt match the > policy > > that it was mapped to. > > > > "Sidd" wrote: > > > > > Hi Dilip, > > > > > > I do not believe the endpoint uri specified in the policy file is > case > > > sensitive. Could you please give me an example of this as this needs to > be > > > investigated ASAP. > > > > > > In you response, if you could let me know if you are using ASMX, or > > > soap.tcp, that would be very helpful as well. > > > > > > Thanks > > > > > > Sidd [MSFT]. > > > > > > "Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message > > > news:232955632424973340264240@msnews.microsoft.com... > > > > Hello DevilDog74, > > > > Yes it is case sensitive and it certainly needs to be addressed > IMO > > > > HTH > > > > Regards, > > > > Dilip Krishnan > > > > MCAD, MCSD.net > > > > dkrishnan at geniant dot com > > > > http://www.geniant.com > > > > > > > > > A client and I worked for 2 days on a WSE issue where the URI > > > > > specified in the policy was all lowercase. The final soap exception > > > > > being dealt with before we got it running was that the current > policy > > > > > did not match the original policy. > > > > > > > > > > The client was making the call to the secured service with a camel > > > > > cased URI, and this was apparently causing an issue. > > > > > > > > > > The client and server were using 2 way encryption and signing as > well > > > > > as a secure channel. After they made the query string all lower > case, > > > > > to match what was in the policy cache config, it all worked. > > > > > > > > > > If you actually used the MSF Design Process, you could classify this > > > > > issue as being undocumented, with low visibility and having a very > > > > > severe impact. > > > > > > > > > > Is this facet of the policy documented in the help somewhere? Why > > > > > would case of the URI have anything to do with anything with regards > > > > > to signed and encryped data? > > > > > > > > > > > > > > > > > > > > > > > >
Hi DevilDog74,
You are getting the WSE402 error because the client policy is not getting enforced, thereby sending out the message in plain, and hence when the message gets to the service, it does not conform to the security requirements specified in the server's policy file. You can verify this by turning on trace at the client side to see if the message is really getting signed/encrypted (or whatever it is that would make it conform to the server's policy) If your endpoint uri's are the same and are lower case in BOTH your client policy as well as your servers policy, then the exception you display below doesn't fit well with your description because if the policy engine indeed did a case sensitive match of the URI, then you would get a different error message, something more along the lines of "No policy could be found for this message", and not a "Message does not conform to the policy". I have tried to modify the X509Signing policy sample that comes with WSE2 SP2, and this is what I have currently: proxy.Url = "http://hostname/X509SignPolicyService/X509SigningService.asmx" client endpoint uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx server endpoint uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx (same as the client's endpoint uri) and I cannot repro it. The policy engine in WSE does not do a normal URI comparison, otherwise the URI's listed above (the proxy.Url and the client endpoint uri) would not be equal. If you could let me know of something that I am missing that would be great. I know this is a pain when it comes to uri comparison's, and any details you can provide me, possibly with a repro using a quickstart (where I can just change the hostname) would be great. This will help me address the issue faster into the product. Thanks, Sidd [MSFT] [quoted text, click to view] "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpressnews:C615ED18-3AC3-487C-AC6D-E436F9843432@microsoft.com... > So, I was able to repro this. In the ide change the URL Behavior from static > to dynamic. This action modifies the web.config file and modifies the > constructor of the proxy. > > In my poliy the endpoint is all lower case. In my web.config, for the > first test using SoftwareMakers post, I made the first letter of the host > name uppercase. This test returned the proper results. > > In the second test, I made the first letter of evey word not in the host > name uppercase and re-ran the test. I received the exception listed below, > so it is cse sensitive, and my point is that doesnt seem to be documented and > costs my organization a lot of time and money and now we have the client > asking if we should event use WSE over something that is so silly compared to > what the end result is. > > From the clients perspective, they cannot see the fact that their data is > signed and encrypted and communicating over a secure channel. All the client > sees is that their web services arent working and they are out 2 days of > development. > > System.Web.Services.Protocols.SoapHeaderException: > Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The > message does not conform to the policy it was mapped to. at > ion(PolicyExpression [quoted text, click to view] > expression, SoapEnvelope message, EndpointReference endpoint, String Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage(action, > Uri requestEndpoint) at > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope > message) at > SoapEnvelope [quoted text, click to view] > envelope) at Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapSer> Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) > at > verMessage [quoted text, click to view] > message) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClient> Message [quoted text, click to view] > message, WebResponse response, Stream responseStream, Boolean asyncCall) a
t > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > methodName, Object[] parameters) at WebServiceWse.myCourseList(String > strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web > references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at > eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in > c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 > > "DevilDog74" wrote: > > > Did you try making the URI dynamic and specifying the uri in the web ..config > > instead of the proxy? > > > > In any case, both the client and the server are on WSE2SP2. > > > > using default endpoint in the policy is not feasablee because why shoud we > > need to maintain 3 policy files that essentially have the same information in > > them except for where the service lives? > > > > The reason we use the named endpoint is because in our real scenario, I have > > dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, all of > > which have the same policy requirements. > > > > "Softwaremaker" wrote: > > > > > I recalled a similar post a few months ago which [Lucien] and [Hervey] > > > replied that: > > > > > > Quote: URI's are treated case sensitive as defined in specifications/RFC > > > (except for the host name part). Arguably this is a bug in IIS and this is > > > 'fixed' in WSE. You could use default endpoint with action string URI's > > > instead (if that would fit into your scenario). > > > > > > Quote: This is a known bug that is fixed and will be in the next release. > > > The action value is to be treated as is (case sensitive) per WS-Addressing > > > spec. > > > I would though recommend against using upper case in host name part. > > > > > > -- > > > Thank you. > > > > > > Regards, > > > William T (Softwaremaker) > > > http://www.softwaremaker.net/blog > > > ========================================= > > > > > > > > > "Sidd" <ElCid@hotmail.com> wrote in message > > > news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > > > > Hi, > > > > > > > > I don't seem to be able to repro this. I have tried all sorts of > > > casing > > > > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate > > > > it if you could send me a small repro, or even if I could send you a repro > > > > and let me know what I am doing wrong. > > > > > > > > Your input on this is very much appreciated. > > > > > > > > Thanks, > > > > > > > > Sidd [MSFT] > > > > > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > > > > news:60025BFF-2E46-4E37-A14E-A58CB6E6F68D@microsoft.com... > > > > > The URIs provided in this scenario are not real, but demonstrate what I > > > am > > > > > talking about, so please bear with me. > > > > > > > > > > We have a service hosted in IIS called myservice.asmx. > > > > >
Hello Sidd, I really appreciate your time on this. I have a sample all boxed
up and ready to go. You can contact me via email at cbertolasio AT gmail dot com AT = @, dot = . Once I get your email, I will forward you the zipped sample. [quoted text, click to view] "Sidd" wrote:
> Hi DevilDog74, > > You are getting the WSE402 error because the client policy is not > getting enforced, thereby sending out the message in plain, and hence when > the message gets to the service, it does not conform to the security > requirements specified in the server's policy file. You can verify this by > turning on trace at the client side to see if the message is really getting > signed/encrypted (or whatever it is that would make it conform to the > server's policy) > > If your endpoint uri's are the same and are lower case in BOTH your > client policy as well as your servers policy, then the exception you display > below doesn't fit well with your description because if the policy engine > indeed did a case sensitive match of the URI, then you would get a different > error message, something more along the lines of "No policy could be found > for this message", and not a "Message does not conform to the policy". > > I have tried to modify the X509Signing policy sample that comes with WSE2 > SP2, and this is what I have currently: > > proxy.Url = > "http://hostname/X509SignPolicyService/X509SigningService.asmx" > > client endpoint > uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx > > server endpoint > uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx > (same as the client's endpoint uri) > > and I cannot repro it. > > The policy engine in WSE does not do a normal URI comparison, otherwise the > URI's listed above (the proxy.Url and the client endpoint uri) would not be > equal. > > If you could let me know of something that I am missing that would be great. > > I know this is a pain when it comes to uri comparison's, and any details you > can provide me, possibly with a repro using a quickstart (where I can just > change the hostname) would be great. This will help me address the issue > faster into the product. > > Thanks, > > Sidd [MSFT] > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > news:C615ED18-3AC3-487C-AC6D-E436F9843432@microsoft.com... > > So, I was able to repro this. In the ide change the URL Behavior from > static > > to dynamic. This action modifies the web.config file and modifies the > > constructor of the proxy. > > > > In my poliy the endpoint is all lower case. In my web.config, for the > > first test using SoftwareMakers post, I made the first letter of the host > > name uppercase. This test returned the proper results. > > > > In the second test, I made the first letter of evey word not in the host > > name uppercase and re-ran the test. I received the exception listed > below, > > so it is cse sensitive, and my point is that doesnt seem to be documented > and > > costs my organization a lot of time and money and now we have the client > > asking if we should event use WSE over something that is so silly compared > to > > what the end result is. > > > > From the clients perspective, they cannot see the fact that their data is > > signed and encrypted and communicating over a secure channel. All the > client > > sees is that their web services arent working and they are out 2 days of > > development. > > > > System.Web.Services.Protocols.SoapHeaderException: > > Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The > > message does not conform to the policy it was mapped to. at > > > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpress > ion(PolicyExpression > > expression, SoapEnvelope message, EndpointReference endpoint, String > action, > > Uri requestEndpoint) at > > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope > > message) at > > > Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage( > SoapEnvelope > > envelope) at > > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope > envelope) > > at > > > Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapSer > verMessage > > message) at > > > System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClient > Message > > message, WebResponse response, Stream responseStream, Boolean asyncCall) a > t > > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > > methodName, Object[] parameters) at WebServiceWse.myCourseList(String > > strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web > > references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at > > eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in > > c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 > > > > "DevilDog74" wrote: > > > > > Did you try making the URI dynamic and specifying the uri in the web > ..config > > > instead of the proxy? > > > > > > In any case, both the client and the server are on WSE2SP2. > > > > > > using default endpoint in the policy is not feasablee because why shoud > we > > > need to maintain 3 policy files that essentially have the same > information in > > > them except for where the service lives? > > > > > > The reason we use the named endpoint is because in our real scenario, I > have > > > dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, > all of > > > which have the same policy requirements. > > > > > > "Softwaremaker" wrote: > > > > > > > I recalled a similar post a few months ago which [Lucien] and [Hervey] > > > > replied that: > > > > > > > > Quote: URI's are treated case sensitive as defined in > specifications/RFC > > > > (except for the host name part). Arguably this is a bug in IIS and > this is > > > > 'fixed' in WSE. You could use default endpoint with action string > URI's > > > > instead (if that would fit into your scenario). > > > > > > > > Quote: This is a known bug that is fixed and will be in the next > release. > > > > The action value is to be treated as is (case sensitive) per > WS-Addressing > > > > spec. > > > > I would though recommend against using upper case in host name part. > > > > > > > > -- > > > > Thank you. > > > > > > > > Regards, > > > > William T (Softwaremaker) > > > > http://www.softwaremaker.net/blog > > > > ========================================= > > > > > > > > > > > > "Sidd" <ElCid@hotmail.com> wrote in message > > > > news:eysEOlZBFHA.3644@TK2MSFTNGP15.phx.gbl... > > > > > Hi, > > > > > > > > > > I don't seem to be able to repro this. I have tried all sorts of > > > > casing > > > > > possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really > appreciate
After working on this issue a bit longer we determined that the url is case
sensitive on a WSE2SP2 machine if there is a binding redirect in the GAC that points all calls to the WSE2SP1 assembly OR the client making the call is WSE2SP1. With a binding redirect, the client is executing WSE2SP1 code, even though WSE2SP2 is installed. I was doing a Binding Redirect to mimic my clients scenario, as my client had WSE2SP1 installed and all of my development workstions and host servers were WSE2SP2 except for 1. In all scenarios where the client calling the service is WSE2SP2, we found that the URL passed to the proxy IS NOT CASE SENSITIVE. [quoted text, click to view] "DevilDog74" wrote:
> Hello Sidd, I really appreciate your time on this. I have a sample all boxed > up and ready to go. You can contact me via email at cbertolasio AT gmail dot > com > > AT = @, dot = . > > Once I get your email, I will forward you the zipped sample. > > "Sidd" wrote: > > > Hi DevilDog74, > > > > You are getting the WSE402 error because the client policy is not > > getting enforced, thereby sending out the message in plain, and hence when > > the message gets to the service, it does not conform to the security > > requirements specified in the server's policy file. You can verify this by > > turning on trace at the client side to see if the message is really getting > > signed/encrypted (or whatever it is that would make it conform to the > > server's policy) > > > > If your endpoint uri's are the same and are lower case in BOTH your > > client policy as well as your servers policy, then the exception you display > > below doesn't fit well with your description because if the policy engine > > indeed did a case sensitive match of the URI, then you would get a different > > error message, something more along the lines of "No policy could be found > > for this message", and not a "Message does not conform to the policy". > > > > I have tried to modify the X509Signing policy sample that comes with WSE2 > > SP2, and this is what I have currently: > > > > proxy.Url = > > "http://hostname/X509SignPolicyService/X509SigningService.asmx" > > > > client endpoint > > uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx > > > > server endpoint > > uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx > > (same as the client's endpoint uri) > > > > and I cannot repro it. > > > > The policy engine in WSE does not do a normal URI comparison, otherwise the > > URI's listed above (the proxy.Url and the client endpoint uri) would not be > > equal. > > > > If you could let me know of something that I am missing that would be great. > > > > I know this is a pain when it comes to uri comparison's, and any details you > > can provide me, possibly with a repro using a quickstart (where I can just > > change the hostname) would be great. This will help me address the issue > > faster into the product. > > > > Thanks, > > > > Sidd [MSFT] > > > > > > > > "DevilDog74" <DevilDog74@discussions.microsoft.com> wrote in message > > news:C615ED18-3AC3-487C-AC6D-E436F9843432@microsoft.com... > > > So, I was able to repro this. In the ide change the URL Behavior from > > static > > > to dynamic. This action modifies the web.config file and modifies the > > > constructor of the proxy. > > > > > > In my poliy the endpoint is all lower case. In my web.config, for the > > > first test using SoftwareMakers post, I made the first letter of the host > > > name uppercase. This test returned the proper results. > > > > > > In the second test, I made the first letter of evey word not in the host > > > name uppercase and re-ran the test. I received the exception listed > > below, > > > so it is cse sensitive, and my point is that doesnt seem to be documented > > and > > > costs my organization a lot of time and money and now we have the client > > > asking if we should event use WSE over something that is so silly compared > > to > > > what the end result is. > > > > > > From the clients perspective, they cannot see the fact that their data is > > > signed and encrypted and communicating over a secure channel. All the > > client > > > sees is that their web services arent working and they are out 2 days of > > > development. > > > > > > System.Web.Services.Protocols.SoapHeaderException: > > > Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The > > > message does not conform to the policy it was mapped to. at > > > > > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpress > > ion(PolicyExpression > > > expression, SoapEnvelope message, EndpointReference endpoint, String > > action, > > > Uri requestEndpoint) at > > > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope > > > message) at > > > > > Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage( > > SoapEnvelope > > > envelope) at > > > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope > > envelope) > > > at > > > > > Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapSer > > verMessage > > > message) at > > > > > System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClient > > Message > > > message, WebResponse response, Stream responseStream, Boolean asyncCall) a > > t > > > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > > > methodName, Object[] parameters) at WebServiceWse.myCourseList(String > > > strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web > > > references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at > > > eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in > > > c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 > > > > > > "DevilDog74" wrote: > > > > > > > Did you try making the URI dynamic and specifying the uri in the web > > ..config > > > > instead of the proxy? > > > > > > > > In any case, both the client and the server are on WSE2SP2. > > > > > > > > using default endpoint in the policy is not feasablee because why shoud > > we > > > > need to maintain 3 policy files that essentially have the same > > information in > > > > them except for where the service lives? > > > > > > > > The reason we use the named endpoint is because in our real scenario, I > > have > > > > dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, > > all of > > > > which have the same policy requirements. > > > > > > > > "Softwaremaker" wrote: > > > > > > > > > I recalled a similar post a few months ago which [Lucien] and [Hervey] > > > > > replied that: > > > > > > > > > > Quote: URI's are treated case sensitive as defined in > > specifications/RFC > > > > > (except for the host name part). Arguably this is a bug in IIS and > > this is
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 |