Двухсторонняя связь через HTTP-прокси

Question

Я пытаюсь найти наиболее подходящий способ сделать двухстороннее сокет-соединение через HTTP-прокси - скажем, это протокол типа telnet. К сожалению, мне также необходимо поддерживать аутентификацию NTLM (с прокси), а также Basic и Digest, в дополнение к любым другим будущим механизмам проверки подлинности, которые я не могу предсказать.

Если бы это было просто базовое и дайджест, я бы сам обработал соединение, но я действительно не хочу застревать в болоте, который является NTLM. Глядя на базовый API AuthenticationManager, он очень привязан к HttpWebRequest, поэтому я не могу использовать эту функциональность, если я использую socket/tcpclient/whatever или даже пишущий новый вывод WebRequest.

Воспроизведение с помощью HttpWebResponse дает поток, который нельзя записать, используя RequestStream после получения потока ответов, дает параллельное исключение io.

Пробежав через все возможности, я могу думать, я пришел с каким-то неприятным кодом, который выходит из-за NetworkStream, связанный с HttpWebRequest, который позволяет два способа связи:

..... 
    HttpWebResponse resp = (HttpWebResponse)req.GetResponse(); 
    Stream str = resp.GetResponseStream(); 

    System.Type type = str.GetType(); 
    PropertyInfo info = type.GetProperty("Connection", BindingFlags.NonPublic|BindingFlags.Instance| BindingFlags.Public); 
    object obj = info.GetValue(str, null); 
    type = obj.GetType(); 
    info = type.GetProperty("NetworkStream", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public); 
    object obj2 = info.GetValue(obj, null); 
    NetworkStream networkStream = obj2 as NetworkStream; 

Что я (он не будет работать с Mono для начала), поэтому мне интересно, есть ли лучший способ использования общедоступных API-интерфейсов, которые позволят мне использовать встроенную функциональность проверки подлинности прокси-сервера.

Answer 1

HTTP - это два пути. Клиенты могут отправлять запрос на передачу данных с использованием HTTP GET (хотя даже тогда данные могут быть помещены в URL-адрес или заголовки), или они могут отправлять данные с помощью HTTP POST, и сервер получает возможность отправлять ответ с заголовками и данными.

Если вы говорите «два пути», вы думали о чем-то более похожем на простой TCP-сокет, где клиент и сервер читают и записывают по своему усмотрению, а затем извините, но это не то, что делает HTTP. Клиент отправляет запрос, а сервер - ответ. Это все. Технически, если у вас не было API-интерфейсов на стороне клиента, обеспечивающих требуемые ограничения HTTP, и вы могли бы подготовить свой собственный нестандартный сервер, вы могли бы иметь несколько клиентов < -> обмены серверами в рамках одного HTTP-протокола запрос, но в этот момент это скорее не будет HTTP, это будет TCP-соединение с HTTP, например, рукопожатие, и ваш прокси-сервер может даже не разрешить его.

Это говорит о том, что вам не нужно вообще писать поток ответов, либо вы довольно смущены, и вам просто нужно сделать POST (см. GetRequestStream), или вы просто немного путают, и вы можете просто отправить новый запрос после того, как вы обработали ответ. Вы даже можете повторно использовать один и тот же экземпляр HttpWebRequest, как только вы вызвали метод .Close на полученном WebResponse. И все это произойдет в одном и том же сокете TCP (если ваш сервер и прокси поддерживают его).

Хорошо, я надеюсь, что все имело смысл. Если он не ответил на ваш вопрос так или иначе, просто предоставьте более подробную информацию о том, что вы пытаетесь сделать в отношении «двусторонней» связи. Я понимаю, что у вас есть ограничение на прохождение HTTP-прокси с требованиями проверки подлинности HTTP, что очень многое ограничивает.