Microsoft Has A Sp #3 Out just found about it

[Saint_Michael 3]

went to the microsoft website and notice they have a new service pak heres the info on the pak

mind you you this is from the read me file that was given on the website

Web Services Enhancements 2.0 Service Pack 3 ReadmeThe Web Services Enhancements 2.0 for Microsoft .NET (WSE) helps developers create interoperable Web services with advanced Web services features. With WSE, you can secure your messages using digital signatures and encryption, send attachments, route messages through intermediaries, and more. WSE comes complete with samples and product documentation. For more information, visit us on the Web.

System Requirements
MicrosoftŽ WindowsŽ XP Home or MicrosoftŽ WindowsŽ XP Professional or MicrosoftŽ WindowsŽ 2000 Professional or MicrosoftŽ WindowsŽ 2000 Server or MicrosoftŽ Windows Server 2003
MicrosoftŽ Internet Information Services (IIS) 5.0, 5.1, or 6.0
MicrosoftŽ .NET Framework version 1.1
Known Issues
The X.509 Certificate tool does not show the security settings for a certificate's key file when the computer is not joined to a domain. To view the security settings, join the machine to a domain or use the Folder Options Control Panel and clear "Use simple file sharing" from the View tab.

The custom security token samples (CustomBinarySecurityToken and CustomXmlSecurityToken) issue security tokens with created times. If these samples are run on two machines, one client and one server, and the clocks of the two machines are not tightly synchronized it is possible that spurious timing related errors may be experienced. For example, if the server clock is ahead of the client clock, the custom security token service effectively issues post-dated security tokens. To avoid this issue, amend the sample code at the point where the lifetime of the issued token is set (search for _lifeTime = new LifeTime(DateTime.Now, 8 * 60 * 60 )) and modif this to not include the DateTime.Now parameter. This creates a token with only an expiration time.

When a message sent from a 3rd party client to WSE2.0 service contains a UsernameToken without Created and Nonce elements, you may encounter an error due to the fact that WSE2.0 expects Created and Nonce elements to be present by default. WSE uses those elements for a simple replay detection mechanism. In order to make WSE accept a UsernameToken without those elements, disable replay detection as described here

Changes for This Release
The WSE 2.0 release contains many important changes from the WSE 1.0 release, including some breaking changes. The following provides a brief summary of the major changes; further information may be found in the product documentation.

Changes made in Service Pack 3
Core product changes:

Security headers created by a SoapHttpRouter are now serialized onto the wire. Previously, when a SoapHttpRouter created a <Security> header with security tokens and child elements, the <Security> header would not be serialized onto the wire.

Security changes:

Policy enforcement for request and response messages have been made more secure by the following changes:

Incoming SOAP responses received by clients that do not contain WS-Addressing headers are now verified against the policy that is mapped for responses sent to the default (anonymous) role endpoint. When there is no default role endpoint specified, an exception is thrown. Previously, these SOAP responses were accepted and bypassed the policy verification check.

Server-side policies that utilize the IdentityToken attribute now work on SOAP faults and SOAP responses. Previously, policies applied to SOAP faults were not enforced when the SecurityToken assertion specified in the policy was an IdentityToken (from the Request) and therefore the fault response was not encrypted with the identity token.

When fault policy cannot be enforced on an outgoing SOAP fault, the SOAP fault contents are placed in an event log and a "server unavailable" fault is sent instead. Previously, SOAP faults would be sent in plain text when the policy associated with it could not be enforced.

A SOAP fault is now generated on incoming SOAP messages to a Web service that contain the same MessageID value as a SOAP request that is currently being processed by the policy system. Previously, an incorrect policy was enforced for SOAP responses from a Web service when two or more incoming SOAP requests were sent to different endpoints that had the same MessageID.

When policy is enabled, all endpoints that messages will be sent to or received from must have an associated endpoint policy. Previously, SOAP messages would be sent out regardless of there being no policy to enforce. Now you must explicitly specify that no policy should be enforced for a given endpoint in the policy file. Note that an empty operation element is now permitted (with the value of "" for policy defaults) or the empty defaultOperation element. This has the meaning of "do not apply policy for this endpoint".


When communicating over the soap.tcp or soap.inproc transports, authentication now correctly occurs when UsernameToken security tokens are used for authentication by a client and a server hosted in the same application domain. Previously, when the client and the server were hosted in the same application domain, no authentication was performed on the server when the client signed with a UsernameToken security token, because both the server and client were sharing the same UsernameToken security token cache.

Stress changes:

It is now possible to send a larger number of one-way messages to the same SoapService. Previously, sending a large number of one-way messages with SoapService hosted by ASP.NET caused a connection close to occur - leading to "Underlying Connection is Closed" exception on the client when under stress. This lead to the client exhausting all available ports as the client kept opening new connections for each request.

WseWsdl2 tool changes:

WseWsdl2.exe now correctly generates EndXXX proxy methods for overloaded method names. Previously WseWsdl2.exe would generate two EndXXX methods with the same method signature for overloaded method names.

Changes made in Service Pack 2
Core product changes:

A new compatibility mode attribute is introduced to select the wire format on the sending side. The mode attribute tells WSE runtime to generate a message compatible to a particular release of WSE. By default, the compatibility mode is set to WSE2RTM. It can be WSE2RTM, WSE2SP1 WSE2SP2 and so on. On the receiving end, a particular version of WSE runtime is able to accept all types of wire format in all its previous releases. In a request-response message exchange, a server generates a response message which is compatible with the request message. The server, by default, still uses the compatibility section to generate its response if it cannot determine the compatibility mode based on the request message.

A new implementation of the Kerberos token based on SSPI interfaces is included in this release. The new token is named KerberosToken2. Please see the reference conceptual documentation for more details on KerberosToken2 and differences between KerberosToken2 and KerberosToken.

The TokenIssuer element in the SecurityToken policy assertion is ignored for the KerberosToken for both incoming and outgoing messages.

The SecurityTokenManager.LoadTokenFromXml method no longer throws an exception when the SecurityToken.IsCurrent property is false. That check is done by the WSE security input filter, which throws an exception when the SecurityToken.IsCurrent property is false.

For security reasons, it is strongly recommended to encrypt Username tokens, especially when they contain password information. The SecurityTokenServiceClient class now automatically encrypts any UsernameToken security tokens included in outgoing SOAP requests. Similarly, the SecurityTokenService class automatically encrypts any UsernameToken security tokens included in outgoing SOAP responses.

The following methods have been added to simplify overriding the default behavior if protection of UsernameToken is provided by other means (e.g. https):
protected virtual void SecurityTokenServiceClient.EnforceRequestUsernameTokenEncryption. Called from the EnforceRequestPolicy method, this method enforces the requirement that any UsernameToken security tokens in an RST message must be encrypted. The issuerToken is used as the encrypting token. This method throws an exception when it cannot encrypt the UsernameToken security tokens in an RST message. Override this method to suppress this behavior.

protected virtual void SecurityTokenService.VerifyRequestUsernameTokenEncryption. Called from the VerifyRequestPolicy method, this method verifies that tokens in an RST message are encrypted. This method throws an exception when it encounters an unencrypted UsernameToken security token in an RST message. Override this method to suppress this test.

protected virtual void SecurityTokenService.EnforceResponseUsernameTokenEncryption. Called from the EnforceResponsePolicy method, this method enforces the requirement that any Username tokens in an RSTR message must be encrypted. The ResponseEncryptingToken is used as the encrypting token. This method throws an exception when it encounters an unencrypted UsernameToken security token in an RST message. Override this method to suppress this test.

protected virtual void SecurityTokenServiceClient.VerifyResponseUsernameTokenEncryption. Called from the VerifyResponsePolicy method, this method verifies that tokens in an RSTR message are encrypted. This method throws an exception when it encounters an unencrypted UsernameToken security token in an RST message. Override this method to suppress this test.

In WSE2.0 SP1 it was impossible to make successive requests for a SecurityContextToken security token, made through a single instance of SecurityContextTokenClient. In WSE2.0 SP2 this issue is fixed. A new method, protected virtual void SecurityTokenServiceClient.ClearRequestSoapContext, has been added as part of the fix for this bug, used to clear security elements and tokens from the soap context after a request was made.

When a class deriving from SecurityTokenServiceClient requires that security elements or tokens in the SoapContext are preserved from one request to another, the new behavior may be suppressed by overriding the ClearRequestSoapContext method.

In request/response scenarios, the SoapService class now sends back an empty SoapEnvelope when a Web service method returns null.

The EncryptedData.Decrypt method only supports decryption of one and only one XML element. A security fault is thrown otherwise.

In the SoapHttpOutputChannel.Send method, if the response has an unsupported content type, such as text/html, the response stream is read and stored in the exception text.

Two new properties, SimpleDisplayName and FriendlyDisplayName, have been added to the X509Certificate class.

The default value of the DerivedKeyToken.Label property has changed from "WS-SecureConversation" to "WS-SecureConversationWS-SecureConversation". This change should have no effect on any of your WSE applications.

When an incoming SOAP message contains multiple security tokens with envelope signature inside those tokens, WSE no longer returns a security fault.

When WSE SOAP messaging classes are used with the HTTP/HTTPS transports, a simple WSE805 exception was thrown when the response content type was not supported. This can occur when an HTTP specific error is returned from the server. Now WSE attempts to read the response stream and throw an WSE805 exception with more detailed error information that is read from the response stream.

The WSE configuration section now allows white space or comments as child nodes for the following configuration elements: <trace>, <policyTrace>, <detailedErrors>, <cache> element for <referral>, <x509>, and <limits>.

When a security context token is deserialized, WSE retrieves a security token from its cache based on its globally unique Identifier. The security token retrieved from the cache sometimes has a different Identifier than the security token received from the incoming message. If that happens, WSE would previously fail to verify a signature or decrypt the message. For Service Pack 2, WSE now assigns the Id of the security token from the incoming message to the security token retrieved from the cache.

The SecurityContextTokenService security token service now caches newly issued SecurityContextToken security tokens after the properties of the IIssuedToken interface have been initialized. Previously, the SecurityContextToken security token was cached before the properties of the IIssuedToken interface had been initialized.

WSE now generates an external security token reference when calculating digital signatures and the security token used to generate the signature is not included in the SOAP message. Previously, WSE would always generate internal security token references. When the security token was not sent with the SOAP message, the receiver would return a security fault.

A client fault is now thrown when WSE tries to verify a signature or decrypt a SOAP message based on a UsernameToken security token that has a plaintext password or no password and the <nonce> and/or <created> elements are not present. Previously, a server fault was thrown.

SoapService instances configured to automatically issue SecurityContextToken (SCT) security tokens no longer re-use the same instance of the SCT issuer. With service pack 2, a new instance is created per request. This instance is accessible via the SoapService.AutoIssueSCTService property. If the old behavior is required, there are two ways to avoid this issue:

override the SoapService.AutoIssueSCTService property to return a singleton instance of a SecurityContextTokenService, or
create a wrapper SecurityContextTokenService that delegates to a singleton instance and register it through configuration.

Starting with WSE2.0 SP2, WSE correctly processes incoming SOAP messages that contain <InclusiveNamespace> elements within an <CanonicalizationMethod> element that is a child element of <SignedInfo>.

In HTTP case, request URI canonicalization rules for WSE policy verification are made consistent with the IIS/ASP.Net canonicalization rules to ensure that messages are always mapped to the correct policies. All forms of the hostnames that map to the same IP address are treated equivalent. "Loopback" localhost|127.0.0.1 address are treated differently from the actual host name/IP address. For example:

http://forums.xisto.com/no_longer_exists/ (brief form) and http://forums.xisto.com/no_longer_exists/ (FQDN) are considered the same endpoint during policy verification.

LOCALHOST/service.asmx and http://forums.xisto.com/no_longer_exists/ are considered different endpoints to allow for different policies for local and remote calls

This change should not affect any of your applications and improves security of WSE applications that use defaultEndpoint policies.

Visual Studio tool integration changes:

The default value for http Routing handler type is fixed to the correct one.

WSE setting tool support for VS C++ project is fixed.

WSE setting tool would always prompt users for confirmation when the Cancel button was clicked. Now it is fixed so that the tool will prompt user only when some changes are made by users.

The Security Settings Wizard can support creating Policy files for remote service.

WseWsdl2 tool changes:

The WseWsdl2 tool now properly generates proxy classes when a Web service uses a Guid type.

If an input schema contains a type definition which is derived from another complex type, the proxy class would generate a class definition for that derived type with incorrect namespace. This is now fixed.

If a schema contains types with names that differ only by letter case, wsewsdl2 used to create invalid VB proxies. This is fixed in SP2.
Changes made in Service Pack 1
Core product changes:

WSE no longer throws an exception due to a SOAP message being signed by a KerberosToken security token in a time zone east of GMT.

The value of the maxTokens attribute for the <limits> element specifies the maximum number of security tokens that may be contained within an incoming SOAP message. Previously, only natively supported security tokens counted towards the limit.

All members of the ElementList class now use by value parameters. Previously, the Remove and IndexOf methods used by reference parameters.

When a SOAP request does not contain a SOAPAction HTTP header, WSE throws an Microsoft.Web.Services2.Addresssing.AddressingFormatException. Previously, a System.NullReferenceException was thrown.

WSE now generates WSDL files with unique operations when a Web service is built using the WSE Messaging API and it contains multiple Web service methods with identical names. Previously, WSE generated an incorrect WSDL document for this scenario.

WSE no longer throws an exception during WSDL generation for Web services built using the WSE Messaging API that contain a method with an System.Xml.XmlElement parameter.

The GetBodyObject method of the Microsoft.Web.Services2.SoapEnvelope class now supports System.Data.DataSet objects.

Invalid policy documents that contain multiple <Role> or <SubjectName> claims in a <SecurityToken> assertion will now fail to load.

SecurityContextToken and UsernameToken security tokens with the same key as a cached security token can now be cached using the CacheSecurityToken method. Previously, the security token would not be cached.

A new protected virtual method, named RaiseDispatchFailed, has been added to the Microsoft.Web.Services2.Messaging.SoapTransport class. Any class derived from SoapTransport can raise the Microsoft.Web.Services2.Messaging.SoapTransport.DispatchFailed event by calling this method.

A new flag named IncludeReferenceProperties has been added to the Microsoft.Web.Services2.Security.SignatureOptions enumeration. This flag can be used to specify that all elements in the SoapContext.Addressing.Destination.ReferenceProperties.AnyElements collection are signed. This flag is only valid for outgoing SOAP messages.

When dispatching a SOAP message based on an Microsoft.Web.Services2.Addressing.EndpointReference, the wsu:Id, SOAP actor and mustUnderstand attributes are now ignored.

While retrieving an x.509 certificate, WSE is now capable of using an RFC3280 compliant algorithm to generate a key identifier for X.509 certificates that do not have the Key Identifier extension. To enable this algorithm, add an <x509> element to the receiving application's configuration file and set the useRFC3280 attribute to "true". The default value for the useRFC3280 attribute, which is new for SP1, is "false". Setting the attribute to "false" specifies that WSE uses an algorithm that is not RFC3280 compliant, as it did prior to SP1.

After processing the SOAP envelope through all the input filters, WSE runtime will remove the SOAP header element if it no longer contains any child elements.

When a security token request does not have an Microsoft.Web.Services2.Policy.AppliesTo (RequestSecurityToken.AppliesTo is null), WSE no longer adds an AppliesTo. Previously, WSE would default the destination to the URL for the security token service.

Visual Studio tool integration changes:

The type attribute for settings on security token managers and binary security token managers is now an optional setting in the WSE Settings 2.0 tool. when the type attribute is not specified, the built-in security token managers are used, such as Microsoft.Web.Services2.Security.Tokens.X509SecurityTokenManager. Previously, it was required.

The Time Tolerance in Seconds setting on the Security tab of the WSE Settings 2.0 tool now updates the <ttlInSeconds> element in the application's configuration file, even if one already exists. Previously, the value was only inserted into the <ttlInSeconds> element when the element was not currently in the configuration file.

The X509Certificates... link on the TokenIssuing tab of the WSE Settings 2.0 tool now opens the certificate store location specified on the Security tab. Previously, it would always open the CurrentUser store.

The Security Settings Wizard can now be used on Microsoft Windows 2000 to select, add, and view X.509 certificates. Previously, the Select Certificate, Add Certificate, and View Certificate buttons were not functional on Windows 2000.

A new check box named Use RFC3280 has been added to the Security tab in the WSE Settings 2.0 tool that enables you to specify that WSE generates RFC3280 compliant key identifiers when an X.509 certificate does not contain the Key Identifier extension. When set, the Policy Wizard generates RFC3280 compliant PKI too.

WseWsdl2 tool changes:

The WseWsdl2 tool now properly generates proxy classes when an Web service exposes multiple operations with the same name but with unique action names. The tool will now create a proxy correctly for this scenario by setting the new UniqueMethodName property of the SoapMethodAttribute class to a unique name.

Proxy classes will now be generated for services containing relative URI values for SOAP action names.

Generated proxy classes for Web service methods that use a DataSet type for a parameter or return value, now use the DataSet type as the Web service method. Previously, the proxy class would generate the System.Xml.XmlElement type for DataSet types.

When a SoapService has an SoapActor attribute applied to it, an EndpointReference with a Via reference property is required to send a SOAP message to the Web service. To build a SoapClient that calls a Web service that has an SoapActor attribute applied to it, use the new WseWsdl2 tool command line parameter, name, and specify the logical name that is specified in the Web service's SoapActor attribute. The generated SoapClient proxy class will correctly address the Web service with a fully specified EndpointReference. For an example of how to specify the EndpointReference without using the WseWsdl2 tool, see the TcpSyncStockService QuickStart sample.

When a WSDL contains a schema definition that is registered with an empty namespace and if any of the message part elements contain a Type attribute the tool will no longer throw an exception.

The WseWsdl2 tool can now process WSDL documents that have nested <import> elements. That is, WSDL documents that contain an <import> element that references a WSDL document, which in turn has an <import> element that references another WSDL document, and so forth. To specify the level of recursion that the WseWsdl2 tool will go through to download the imported WSDL documents, two new command line parameters have been added to SP 1: noRecursion and recursionLevel. To specify how many levels of recursion you want the tool to go through, use the recursionLevel followed by an integer representing the number of levels or documents you want the tool to go through. The default is 3. If you do not want the tool to download WSDL documents specified in <import> elements, use the noRecursion command line parameter. If both parameters are used, the noRecursion parameter takes precedence.

Like the WSDL.exe tool, the WseWsdl2 tool now generates methods to communicate with a Web service asynchronously. That is, for every Web service method, a BeginXXX and EndXXX method are generated. The XXX in the name of the method is the name of the synchronous method. Use the BeginXXX method to initiate an asynchronous call and the EndXXX method to complete it.

X509 Certificate Tool changes:

When choosing a certificate, the X509 Certificate tool will also display the RFC3280 compliant PKI for that certificate.

New Features for Version 2.0
The assembly name has been changed from Microsoft.Web.Services.dll to Microsoft.Web.Services2.dll. The root namespace has been changed to Microsoft.Web.Services2.

Support for new Web services specifications including WS-Addressing, WS-Policy, WS-Security Policy, WS-Trust, and WS-Secure Conversation. Policy allows configuration-based declaration of security requirements for incoming and outgoing SOAP messages. Policy also allows significant extensibility mechanisms for user-defined policies.

New lightweight, message-oriented, SOAP programming model with support for TCP/IP and HTTP transports. See the documentation for more information.

Support for security tokens based on Kerberos tickets. This support is operating system platform dependent. In particular, Windows 2000 and Windows XP require elevated privileges at the server to process Kerberos tokens. See the documentation for additional information.

Support for the IPrincipal interface on tokens to allow the use of the IsInRole method for authorization. Built-in support for mapping UsernameToken or Kerberos tokens to Windows principals.

A security settings wizard that helps secure an application by generating a policy for the application. Invoke the security settings wizard from the Policy tab of the WSE 2.0 Settings tool.

QuickStart samples are provided in the C# and Visual Basic languages.

Major Class Library Changes from Version 2.0 Technology Preview
This list is not comprehensive but highlights the major changes, some of them breaking, from the WSE 2.0 Technology Preview object model.

The Policy mapping model has changed. There is now a single file that contains both the send and receive mapping. See the documentation for more information.

SecurityContextToken security tokens can now be issued automatically by a Web service. The <autoIssueSecurityContextToken> element in the configuration file turns this on. SecurityContextToken security tokens issued by 3rd parties are no longer supported out-of-box and require customized coding.

Security context tokens can now be issued automatically by a service. The <autoIssueSecurityContextToken> element in the configuration file turns this on.

The Microsoft.Web.Services2.Security.Signature class is obsolete. Use the Microsoft.Web.Services2.Security.MessageSignature class instead.

The Microsoft.Web.Services.Routing namespace has been removed. The HTTP Router is now supported as Microsoft.Web.Services2.Messaging.SoapHttpRouter

The interfaces for transports and channels have been reworked.

Custom transports may be registered in the app.config / web.config files. Existing transports may be removed and/or reconfigured. See the WSE.config file for examples and additional information.

The Microsoft.Web.Services.Security.SecureConversation namespace has been moved into the Microsoft.Web.Services2.Security namespace.

The Microsoft.Web.Services.Trust namespace has been moved into the Microsoft.Web.Services2.Security namespace.

The incorrectly named Microsoft.Web.Services.Security.SaML class has been renamed to Microsoft.Web.Services2.Security.SAML and contains a more complete set of definitions.

Major Class Library Changes from Version 1.0
This list is not comprehensive but highlights the major changes, some of them breaking, from the WSE 1.0 object model.

The Microsoft.Web.Services.HttpSoapContext class has been marked obsolete with this release. This class was ASP.NET specific and could not support the multi-protocol capabilities of this release. The new classes Microsoft.Web.Services2.RequestSoapContext and Microsoft.Web.Services2.ResponseSoapContext provide equivalent support through their static Current properties. Applications should use these classes to access the request and response SoapContext objects. Note that these classes contain valid contexts only during execution of the service code itself; they are not valid during pipeline execution. Filters that need to access the SoapContext associated with the SoapEnvelope being processed can use the new static Microsoft.Web.Services2.SoapContext.Current property.

Significant changes have been made to security token support in WSE 2.0. WSE 1.0 custom binary security tokens will not work with WSE 2.0. The new support centers around Microsoft.Web.Services2.Security.Tokens.ISecurityTokenManager implementations. The custom binary and custom XML token samples illustrate the use of this new support.

The default constructor has been removed from the SecurityToken abstract base class. In its place, a new constructor has been introduced that takes a string to specify the security tokenââŹs token type. All of the standard token types are specified in the WS-SecurityPolicy specification. For BinarySecurityToken objects, the value type of the token is used as its token type. For example, the token type for an X509CertificateToken is "http://forums.xisto.com/no_longer_exists/ ".

The Microsoft.Web.Services.Routing namespace and its classes have been removed. The Microsoft.Web.Services2.Addressing namespace contains most of the replacement functionality.

Support for signing and/or encrypting of security tokens in a SOAP message.

The Microsoft.Web.Services.Security.IDecryptionKeyProvider interface and the Microsoft.Web.Services.Security.DecryptionKeyProvider class have been removed. The <decryptionKeyProvider> configuration element has also been removed. The functionality of the decryption key provider has been moved into the new Microsoft.Web.Services2.Security.ISecurityTokenManager interface to produce a more general model for retrieving tokens in different scenarios. A base class implementation, Microsoft.Web.Services2.Security.SecurityTokenManager, is built in to the WSE. A new <securityTokenManager> configuration element is used to specify the type that handles a particular type of security token.

Direct support for encryption using an EncryptionKey has been made removed. The relevant constructors for the Microsoft.Web.Services2.Security.EncryptedData class have been removed. Signing and encryption operations require the use of a SecurityToken and decryption operations use the new Microsoft.Web.Services2.Security.ISecurityTokenManager model.

The Microsoft.Web.Services2.SoapContext class exposes the IsInbound property. This read-only property indicates that a Microsoft.Web.Services2.SoapContext instance encapsulates the context information for a received message.

The Microsoft.Web.Services2.SoapContext class exposes the IsRequest property. This read-only property indicates that a Microsoft.Web.Services2.SoapContext instance encapsulates the context information for an incoming either a one way message or a request message in the request-response messaging model.

QuickStart Samples
The following file contains definitions of all the configuration sections that are supported by the product. It supplements the configuration material provided in the documentation and provides information on some late-breaking controls.

WSE Messaging API
The soap.inproc transport protocol is not supported for production environments. That is, the soap.inproc protocol, which can be used to send SOAP messages to and from components within the same application domain using the WSE Messaging API, is for testing purposes only.

QuickStart Samples
WSE does not include prebuilt versions of the QuickStart samples. Please refer to the readme.htm file in the Samples directory for instructions on building and configuring the samples.

Schemas
The following file contains links to schemas for the protocols that WSE supports.

Documentation Errata
Care should be taken when using policy with messages that are routed on body content. Policy maps messages to methods using the SOAP action. When a message is routed by body content the policy mapping mechanism still relies on the SOAP action of the message. It is recommended other message verification mechanisms than Policy should be used for messages when the SOAP action is not used for dispatching the message.

Edited April 14, 2005 by Saint_Michael (see edit history)

[ill 0]

you should of quoted all that..as for the new sp3. i'm not reading all that bs. tell me what they changed in english.

[Saint_Michael 3]

i will put it like this more hacking time for the hackers

[no9t9 0]

I guess mods need hosting credits too. If it were a "regular" user, that would have been marked as spam and hosting credits would have been deducted...

[dundun2007 0]

It has nothing to do if you are a moderator or not, he will not get the hosting credits for it. They are in quotes now and i hope he remembers that in the future. I never heard the new sp3 either, i dont think anyone is going to want to read that whole thing so why not just give us the main points on whats going on here. I just hope it doesnt have a big issue like the sp2 had.

[Saint_Michael 3]

im a dumbass i will admit it , it look like it s more for the administration side of web developing but some security issues have been made for windows too

[fsastraps 0]

I honestly dont even have sp1 if there is one. and I now have LongHorn, so i guess it doesnt matter. To me at least

[NeXDesigns 0]

longhorn? really? is it good? i cant seem to find a good download of it.

[choetry 0]

awww... not another super big download... I downloaded service pack 2 last year and it ate up a lot of my internet credit:p I am so cheapskate

[canute24 0]

Just think how many posts would have used that space used for the quote? A link and a paragraph of quote would have been enough I think.

 

I guess mods need hosting credits too.  If it were a "regular" user, that would have been marked as spam and hosting credits would have been deducted...

129191[/snapback]

I hope you know that quotes don't give hosting credits. Seems to be like a joke but I am not sure.

[ill 0]

canute, at the beginning, the dude didn't use quotes..

[psychiccyberfreak 0]

I wish that microsoft would make the new windows finalized before they reliese it to the public, b/c windows 98 was probably the best, but nobody wants it anymore because of windows XP. I'm working on a top secret project that helps this, but I wont tell you all or else my idea will go bie-bie.

[twentyinches631 0]

Forget that, I still refuse to get Service Pack 2. Installing it messed up my wireless connections. When I uninstalled it, Microsoft Update still recoginized my computer as having the update, and it caused all sorts of problems. I ended up having to format and start over.

[midnightvamp 1]

I wish I could get the updates... there have been times when my computer asks for one of the service packs, and since I don't have it, I can't end up doing what I want with my system.We were told at school not to download the service packs as well, because it will mess with the network at school or something, so I don't want that to happen. It's just a disappointment when I want to use a feature that the computer should have had, but could be added with the pack that I'm not allowed to download.Oh well. I'm probably better off this way, as I haven't wrecked my computer *too* many times

[spawn_syxx9 1]

I probably already have it seince my computer is on auto dl upgrades.