Sunday, June 3, 2012
Requiring SSL over HTTP WCF with an upstream proxy
Its a common problem with WCF services that you have a deployment infrastructure that will strip the SSL before the traffic arrives at your service. This is so the site only needs one certificate but can still use a farm of servers to respond to requests. A proxy or firewall holds the certificate and strips the SSL out before forwarding traffic onto the server farm. There are reasons why you may still require specifying TransportEncryption (SSL) in your service config. When you do the service will fail because SSL is expected but traffic received is not encrypted.
To fix this problem Michelle Leroux Bustamate of IDesign has provided a solution here.
There is also a hot-fix published by Microsoft, that adds the enableUnsecuredResponse attribute and this is reputed to solve the issue as well. Although I haven't personally tried it.
To fix this problem Michelle Leroux Bustamate of IDesign has provided a solution here.
There is also a hot-fix published by Microsoft, that adds the enableUnsecuredResponse attribute and this is reputed to solve the issue as well. Although I haven't personally tried it.
A word of warning regarding manual GC
I was party to an email conversation discussing manual manipulation of the GC. Originally the thread was discussing extreme memory and performance management. Stephen Cohen, Senior Architect at Microsoft added the following response:
A quick word of warning;
Calling the GC is possible but generally not wise. In many scenarios you will find performance drops. Worse yet, the GC is not limited to a single application (unless you are the only application on a device/server). Calling GC might seem good for you but what about any other application that could be impacted?
In my experience wanting to call the GC directly should raise a flag on the application design and set of a deep design review to investigate before implementing a change. With rare exception you can find a way to manage the flow of data, the size of chunks, number of instances, use of critical sections or parallel processing, etc that will remove the need to call the GC.
That said, it can be done but you should allocate a lot of time to test with enough instrumentation that you can both validate a positive result … better performance than the baseline… and confirm no negative side effects.
A quick word of warning;
Calling the GC is possible but generally not wise. In many scenarios you will find performance drops. Worse yet, the GC is not limited to a single application (unless you are the only application on a device/server). Calling GC might seem good for you but what about any other application that could be impacted?
In my experience wanting to call the GC directly should raise a flag on the application design and set of a deep design review to investigate before implementing a change. With rare exception you can find a way to manage the flow of data, the size of chunks, number of instances, use of critical sections or parallel processing, etc that will remove the need to call the GC.
That said, it can be done but you should allocate a lot of time to test with enough instrumentation that you can both validate a positive result … better performance than the baseline… and confirm no negative side effects.
Manipulating the GC will affect other .NET applications running on the server.
Subscribe to:
Posts (Atom)