Two-way communication via HTTP proxy

I'm trying to come up with the most appropriate way to make a two-way socket connection through an HTTP proxy - let's say this is a protocol like telnet. Unfortunately, I also need to support NTLM authentication (with a proxy server), as well as Basic and Digest, in addition to any other future authentication mechanisms that I cannot predict.

If it were just a basic and digest, I would handle the connection myself, but I really do not want to get stuck in a swamp, which is NTLM. If you look at the basic AuthenticationManager API, it is very attached to HttpWebRequest, so I cannot use this function if I use socket / tcpclient / whatever or even write new WebRequest output.

Playback with HttpWebResponse gives a stream that cannot be recorded using RequestStream after the response stream has been restored, giving a parallel io exception.

After going through all the possibilities that I can think of, I came up with some nasty code that gives NetworkStream related to HttpWebRequest, which allows two-way communication:

..... 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; 

Which I'm pretty pushed away (it won't work with Mono for starters), so I'm wondering if there is a better way to use public APIs that will allow me to use the built-in proxy authentication functionality.

+4
source share
1 answer

HTTP is two ways. Clients can send a request for data transfer using HTTP GET (although even then data can be placed in the URL or headers), or they can send data using HTTP POST, and the server sends a response with headers and data.

If you say two ways, you are thinking of something more like a simple TCP socket, where the client and server read and write as they wish, and then excuse me, but that’s not what HTTP does. The client sends a request, and the server sends a response. All this. Technically, if you did not have client-side APIs providing the required HTTP restrictions, and you could prepare your own custom server, you could have several client and server exchanges within the same HTTP protocol request, but at this point it probably will not be HTTP, it will be a TCP connection with HTTP, for example, a handshake, and your proxy server may not even allow it.

However, it looks like you don’t have to write to the response stream at all, or you are rather confused, and you just need to do a POST (see GetRequestStream), or you are just a little confused, and you can just send a new request after You have processed the response. You can even reuse the same instance of HttpWebRequest as soon as you call the .Close method on the received WebResponse. And all this will happen on the same TCP socket (if your server and proxies support it).

Ok, I hope everything made sense. If he didn’t answer your question one way or another, just provide more details about what you are trying to do regarding “two-way” communication. I understand that you have a restriction on passing an HTTP proxy with HTTP authentication requirements, which limits a lot.

+2
source

All Articles