Ответ 1
Вы можете использовать механизм трассировки System.Net, чтобы просмотреть необработанные HTTP-запросы, отправленные на провод. Вы также можете добавить свой собственный tracelistener к процессу.
Я знаю, что вы все будете отвечать "использовать прокси-сервер отладки, такой как Fiddler", но это не так просто.
Вот моя ситуация: у меня есть код, который выполняется на сервере, в ASP.NET-странице с кодом (aspx.cs), который (между прочим) устанавливает соединение с другим сервером, захватывает некоторые вещи и затем форматирует его и возвращает его в браузер.
Проблема в том, что другой сервер делает неправильную вещь, и поэтому я хочу иметь возможность передать флаг отладки на страницу (через строку запроса, например? debug = true), чтобы она распечатывала полностью необработанный HTTP-запрос, который он отправляет на другой сервер, чтобы я мог видеть, что это за ошибка. Этот код работает в нескольких местах, поэтому я хочу иметь возможность просто передать этот флаг на dev, промежуточном или производственном процессе и просто увидеть запрос, не имея необходимости выяснять, могут ли производственные серверы разговаривать с некоторым прокси-сервером, который существует где-то, и т.д.
Вы могли бы подумать, что было бы легко сделать это, не так ли? Поэтому я чувствую, что я сумасшедший или что-то, но я посмотрел ссылку на HttpWebRequest и его родительский класс WebRequest и - ничего. Нет. Вы бы подумали, что Microsoft подумала бы об этом. Самое близкое, что вы можете получить доступ к коллекции "Заголовки", но когда я это пробовал, он опустил некоторые действительно важные заголовки, такие как "длина содержимого", поэтому он должен "лгать" мне (я знаю, что это врет, потому что я знаю за того, что удаленный сервер возвращает статус 200 - запрос успешный, он просто возвращает плохие/разные/неправильные данные)
Вот пример кода для запроса:
HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://www.whatever.com");
req.Method = ... whatever ...;
... other setup for the request ...
/* At this point we are about to send the request.
What does the raw HTTP request look like? */
HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
Вы можете использовать механизм трассировки System.Net, чтобы просмотреть необработанные HTTP-запросы, отправленные на провод. Вы также можете добавить свой собственный tracelistener к процессу.
Я понимаю, что это старый вопрос. Ответ @feroze говорит о том, что делать, но не раскрывает подробностей о том, как настроить трассировку System.Net
для ее достижения.
Поскольку этот вопрос был первым результатом Google для моего запроса по теме, и, поскольку мы все занятые люди, я подумал, что спасу всех вас от необходимости выслеживать эту информацию.
System.Web
очень мощен для отладки HttpWebRequest
и может быть легко настроен с помощью web.config
:
<configuration>
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net" maxdatasize="1024">
<listeners>
<add name="MyTraceFile"/>
<add name="MyConsole"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="MyTraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log" />
<add name="MyConsole" type="System.Diagnostics.ConsoleTraceListener" />
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
</switches>
</system.diagnostics>
</configuration>
При добавлении простого HttpWebRequest
в ваш код и запуске в режиме отладки в Visual Studio в консоли отладки будет отображаться следующая информация:
System.Net Verbose: 0 : [6596] WebRequest::Create(https://example.com/service.asmx)
System.Net Verbose: 0 : [6596] HttpWebRequest#62063506::HttpWebRequest(https://example.com/service.asmx#11234)
System.Net Information: 0 : [6596] RAS supported: True
System.Net Verbose: 0 : [6596] Exiting HttpWebRequest#11234::HttpWebRequest()
System.Net Verbose: 0 : [6596] Exiting WebRequest::Create() -> HttpWebRequest#11234
System.Net Verbose: 0 : [6596] HttpWebRequest#11234 ::GetRequestStream()
System.Net Verbose: 0 : [6596] ServicePoint#11234 ::ServicePoint(example.com:443)
System.Net Information: 0 : [6596] Associating HttpWebRequest#11234with ServicePoint#11234
System.Net Information: 0 : [6596] Associating Connection#11234 with HttpWebRequest#11234
System.Net Information: 0 : [6596] Connection#11234 - Created connection from x.x.x.x:xx to x.x.x.x:xx.
System.Net Information: 0 : [6596] TlsStream#11234 ::.ctor(host=example.com, #certs=0)
System.Net Information: 0 : [6596] Associating HttpWebRequest#11234 with ConnectStream#11234
System.Net Verbose: 0 : [6596] Exiting HttpWebRequest#11234 ::GetRequestStream() -> ConnectStream#11234
System.Net Verbose: 0 : [6596] ConnectStream#7740977::Write()
System.Net Verbose: 0 : [6596] Data from ConnectStream#11234::Write
System.Net Verbose: 0 : [6596] 00000000 : 3C 73 6F 61 70 3A 45 6E-76 65 6C 6F 70 65 0D 0A : <soap:Envelope..
...etc
Я нашел это особенно полезным, когда пытался выяснить причину ошибки клиента веб-сервиса. Оказалось, мне не хватало заголовка.
Вы можете использовать сниффер сетевого трафика, например wireshark.
Это не прокси-сервер отладки, но будет обнюхивать весь трафик и просматривать сырые запросы/ответы.
отвечая на мой собственный вопрос здесь, потому что я думал о другом способе сделать это. В основном идея заключается в том, что вы перенаправляете HttpWebRequest на страницу, которая регистрирует входящий необработанный HTTP-запрос. Другими словами, настроить пользовательский обработчик HTTP в соответствии с этим сообщением форума:
http://forums.asp.net/t/353955.aspx
И затем измените только URL-адрес в HttpWebRequest, чтобы указать на эту новую конечную точку, но сохраните все остальные элементы запроса одинаково. Напишите результат в файл или что-то еще, и вы золотые.
Я предлагаю вам скачать Telerik Fiddler для захвата входящего/исходящего трафика.
Вот простой пример, как это сделать с помощью этого инструмента:
Другое предложение. Внедрите свой собственный веб-прокси и задайте свой запрос, чтобы использовать его с WebRequest.Proxy. Затем вы сможете извлечь трафик из экземпляра прокси.
Изменить: обновить ссылки.
Вы говорите, что считаете, что .NET лжет вам, и конкретный пример, который вы даете, состоит в том, что заголовок Content-Length
отсутствует в ответе HTTP.
Но заголовок Content-Length
не требуется из ответа HTTP. На самом деле, если тело ответа находится в любой динамике, и если его длина неизвестна заранее, то весьма вероятно, что заголовок Content-Length
будет опущен!
Я знаю, что это старый вопрос, но я оказался в трудном положении, когда я не управлял файлом конфигурации приложения, поэтому мне нужен был простой способ включить трассировку через код, а затем легко получить доступ к необработанным данным запроса/ответа в событие. Поэтому я собрал этот пользовательский класс, HttpRawTraceListener, который может быть полезен для других, находящихся на моей позиции:
https://github.com/jhilgeman/HttpRawTraceListener/blob/master/HttpRawTraceListener.cs
Он был разработан так, чтобы было просто добавить файл в проект, а затем вызвать:
System.Diagnostics.HttpRawTraceListener.Initialize();
... чтобы начать след. Оттуда запросы/ответы будут проанализированы из сообщений трассировки, а затем будут доступны через событие System.Diagnostics.HttpRawTraceListener.FinishedCommunication.
Вероятно, он не на 100% идеален для каждого сценария (например, это не прокси-сервер, поэтому он не будет захватывать веб-запросы из браузера, например), но он довольно хорошо работает для захвата запросов/ответов HttpWebRequests к веб-службам, и это может быть хорошей отправной точкой, если вам нужно что-то подобное.
Мне нужно что-то упустить, потому что получение необработанного HTTP-запроса в виде текста ASCII очень просто, пока вы его хватаете в Page_Init(), оно будет отличаться от Page_Load().
protected void Page_Init(object sender, EventArgs e)
{
//this gets the raw request as an ASCII String.
byte[] biData = Request.BinaryRead(Request.TotalBytes);
string sWholeRequestAsString = System.Text.Encoding.ASCII.GetString(biData);
}