Как использовать Fiddler для мониторинга службы WCF

У меня есть служба WCF, которая принимает сложный тип и возвращает некоторые данные. Я хочу использовать Fiddler, чтобы посмотреть, как выглядят входящие запросы к службе. Клиент - это консольное приложение .net, которое использует прокси-сервер ссылки на службу. Возможно ли это с Fiddler. Я новичок в этом инструменте и раньше использовал его только для публикации данных с помощью конструктора запросов.

Вам нужно добавить это в свой web.config

<system.net>
  <defaultProxy>
    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>

1. затем запустите Fiddler на машине WEBSERVER.
2. Щелкните Инструменты | Параметры Fiddler => Подключения => настройте порт на 8888. (разрешите удаленный доступ, если вам это нужно)
3. Хорошо, затем из меню файла захватите трафик.

Это все, но не забудьте удалить строки web.config после закрытия скрипта, потому что, если вы этого не сделаете, это приведет к ошибке.

Ссылка: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy

Fiddler слушает исходящие запросы, а не входящие, поэтому вы не сможете отслеживать все запросы, поступающие в вашу службу, с помощью Fiddler.

Лучшее, что вы получите от Fiddler, - это возможность видеть все запросы по мере их создания вашим консольным приложением (при условии, что приложение генерирует веб-запросы, а не использует какой-либо другой конвейер).

Если вам нужен более мощный (но более сложный в использовании) инструмент, который позволит вам отслеживать ВСЕ входящие запросы, вам следует попробовать WireShark.

редактировать

Я исправился. Спасибо Эрику Лоу за публикацию инструкций по настройке Fiddler в качестве обратного прокси !

У меня была эта проблема, у меня сработало использование localhost.fiddler:

 <endpoint address="http://localhost.fiddler/test/test.svc"
            binding="basicHttpBinding" 
            bindingConfiguration="customBinding" 
            contract="test" 
            name="customBinding"/>

Обобщение предостережений, упомянутых в комментариях / ответах, для нескольких вариантов использования.

В основном см. Http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

• Запустите Fiddler перед своим приложением

• В консольном приложении вам может не понадобиться указывать proxyaddress:

  <proxy bypassonlocal="False" usesystemdefault="True" />

• В веб-приложении / чем-то, размещенном в IIS, вам необходимо добавить proxyaddress:

  <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />

• Когда .NET делает запрос (через клиент службы или HttpWebRequestт. Д.), Он всегда будет обходить прокси-сервер Fiddler для URL-адресов, содержащихся localhost, поэтому вы должны использовать псевдоним, например имя машины, или создать что-то в вашем файле 'hosts' (вот почему что то вроде localhost.fiddlerили http://HOSTNAMEработает)

• Если вы укажете proxyaddress, вы должны удалить его из своей конфигурации, если Fiddler не включен, или любые запросы, которые делает ваше приложение, вызовут исключение, например:

  Невозможно установить соединение, поскольку целевая машина активно отказалась от него 127.0.0.1:8888

• Не забудьте использовать преобразования конфигурации, чтобы удалить секцию прокси в продакшене.

Все, что вам нужно, это изменить адрес в клиенте конфигурации: вместо localhost измените имя компьютера или IP

Это просто, если у вас есть контроль над клиентом, который отправляет сообщения. Все, что вам нужно сделать, это установить HttpProxy в классе обслуживания на стороне клиента.

Я сделал это, например, для отслеживания клиента веб-службы, запущенного на смартфоне. Я установил прокси на этом клиентском подключении к IP / порту Fiddler, который работал на ПК в сети. Затем приложение для смартфона отправило все исходящие сообщения в веб-службу через Fiddler.

Это сработало отлично.

Если ваш клиент является клиентом WCF, просмотрите эти вопросы и ответы, чтобы узнать, как настроить прокси.

Даже если у вас нет возможности изменять код клиентского приложения, вы можете настроить прокси-сервер административно, в зависимости от стека веб-сервисов, который использует ваш клиент.

Стандартная трассировка / диагностика WCF

Если по какой-то причине вы не можете заставить Fiddler работать или предпочитаете регистрировать запросы другим способом, другой вариант - использовать стандартные функции трассировки WCF. Это создаст файл с удобным средством просмотра.

Документы

См. Https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging

Конфигурация

Добавьте в конфигурацию следующее, убедитесь, что оно c:\logsсуществует, перестройте и сделайте запросы:

  <system.serviceModel>
    <diagnostics>
      <!-- Enable Message Logging here. -->
      <!-- log all messages received or sent at the transport or service model levels -->
      <messageLogging logEntireMessage="true"
                      maxMessagesToLog="300"
                      logMessagesAtServiceLevel="true"
                      logMalformedMessages="true"
                      logMessagesAtTransportLevel="true" />
    </diagnostics>
  </system.serviceModel>

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information,ActivityTracing"
        propagateActivity="true">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener"
        name="xml" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Я использовал инструмент Wire Shark для мониторинга вызовов службы из приложения Silver Light в браузере в службу. попробуйте ссылку дает четкую информацию

Это позволяет вам контролировать все содержимое запроса и ответа.

Я просто попробовал первый ответ Брэда Рема и пришел к этому параметру в web.config в разделе BasicHttpBinding:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
        ...
      </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

Надеюсь, это кому-то поможет.

Вы можете использовать бесплатную версию HTTP Debugger.

Это не прокси, и вам не нужно вносить никаких изменений в web.config.

Кроме того, он может показать и то, и другое; входящие и исходящие HTTP-запросы. HTTP-отладчик бесплатно