Add support for tests to use fiddler proxy #89
Conversation
With this change, you can specify /p:UseFiddler=true to build.cmd and the special hostname localhost.fiddler will be used. This causes the localhost proxy bypass to be skipped and the requests will be put through the defined proxy server. Fiddler then strips off the .fiddler from the hostname and passes on the request with the Host being just localhost. Some tests fail when using fiddler as the failure mode changes and there's not a lot we can do about that, but this does give greater flexibility to debugging product/test issues.
| @@ -5,6 +5,29 @@ | |||
|
|
|||
| public static class BaseAddress | |||
| { | |||
| #if USE_FIDDLER | |||
| // Base address for testing nonexistent endpoints | |||
There was a problem hiding this comment.
This approach is really a special case of what I intended in #29. So if we do this approach, we will need to back it out when we do it right -- which I think consists of propagating an MSBuild property ("WcfBaseURL"?) into the build. It also is affected by the Bridge conversations, because the URI's will be provided by Bridge. So it probably means we need to be able to specify the URL of the Bridge itself, as well as the base address we want Bridge to prepend if it chooses localhost. This means we should really drive this requirement into the Bridge discussion, so that we can best choose how Bridge gets configured.
There was a problem hiding this comment.
BTW, my thinking went something like this -- using the new lightweight name-value pair config API's, write an MSBuild task that generates code at build time to populate the name-value pairs directly from available MSBuild properties. Tests could them poll these name-value pair for things like Bridge URL, Fiddler prefix, etc.
There was a problem hiding this comment.
I definitely agree we need a general solution to this problem. The test Bridge host will be driving the hostname used so long term it makes sense to have this problem solved via the config mechanism we use there. I had an itch I needed to scratch today which was get fiddler working on localhost for our existing outer loop tests so figured I would generalize the solution so others could easily benefit (and I wouldn't need to keep a local copy of these changes in sync 😃 .) I have no problem with this being a stop-gap solution. I would like to see us not need to use fiddler in the long run as I would eventually like to have some inspection mechanism built into either the bridge or the client.
There was a problem hiding this comment.
Fiddler is very helpful when debugging issues related to requests. I'd vote we check this in now and modify it when we have the long term solution.
There was a problem hiding this comment.
Please update the Bridge bug to request configurability of base address to allow things like this. Also please update #29 to remove this code when we do it right.
|
This looks like it'd be a good addition to our current (very minimal) arsenal of tools we can use to diagnose issues - it seems self-contained enough too that we could back it out pretty easily when the bridge comes into play. LGTM. |
|
LGTM, subject to my replacing this shortly with #29 |
Add support for tests to use fiddler proxy
With this change, you can specify /p:UseFiddler=true to build.cmd and the special hostname
localhost.fiddler will be used. This causes the localhost proxy bypass to be skipped and the
requests will be put through the defined proxy server. Fiddler then strips off the .fiddler
from the hostname and passes on the request with the Host being just localhost.
Some tests fail when using fiddler as the failure mode changes and there's not a lot we can
do about that, but this does give greater flexibility to debugging product/test issues.