.NET Framework Bookmark and Share   
 index > Network Class Library (System.Net) > HttpWebRequest CONNECT method - writing data after connection
 

HttpWebRequest CONNECT method - writing data after connection

I have successfully connected to a remote server through a proxy using HttpWebRequest with the Method property set to "CONNECT".However it only seems possible to read data from the stream once connected, making the connection useless since I can't interact with the server that was the target of the CONNECT.

Sample code:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://remote.server.name:999");
request.Method = WebRequestMethods.Http.Connect;
request.Proxy.Credentials = CredentialCache.DefaultNetworkCredentials;
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
Stream stream = response.GetResponseStream();
byte[] input = new byte[10240];
stream.Read(input, 0, input.Length);
byte[] output = GetData();
// I would like to be able to do the following, but a NotSupportedException is thrown (Message: "The stream does not support writing.")
stream.Write(output, 0, output.Length);

Looking at the data in "input" (from the snippet above), the connection to the remote server (i.e. tunnelled through the proxy using CONNECT), however at this point I ought to be able to access a 2-way data-stream, butthe response stream is read only so there's no way to continue communication with the remote server.

The advantage of using HttpWebRequest is that it takes care of NTLM proxy authentication required for the particular proxy I'm connecting through which would be time consuming to re-implement using plain TCP sockets.

Is there any way to get a 2-way connection in this situation?
  •  
cosborne
You should not perform the CONNECT operation in your code, according to the HTTP RFC:

9.9 CONNECT

This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [44]).

HttpWebRequest will send the CONNECT request for you in the case you're going to a server requiring SSL (https)

If your intention is to send data to the server, you need to change the verb to a POST and write to the RequestStream, not the ResponseStream as in the code samples at http://msdn.microsoft.com/en-us/library/d4cek6cc(VS.71).aspx

I hope this information helps you in modifying your code

Thanks
Reymarx Gereda [MSFT]
Reymarx Gereda
The server on the "other side" of the proxy isn't a web server, so POST will not work, but tunnelling through an (HTTP) proxy is exactly what I am trying to do. HttpWebRequest is obviously quite capable of doing since it does just that for HTTPS requests through a proxy.

Going the non-HttpWebRequest would effectively require me to write a component that can speak HTTP to the proxy, and perform NTLM authentication (the only method supported by the proxy I am behind), but HttpWebRequest already does both of these things, and so this would seem rather like reinventing the wheel.

Why such obviously useful functionality isn't exposed to user code is frankly beyond me.
cosborne
HttpWebRequest is intended for communicating with Web Servers (sending HTTP requests and receiving HTTP responses).

You could perform the CONNECT operation with the proxy and then use NegotiateStream http://msdn.microsoft.com/en-us/library/system.net.security.negotiatestream.aspxto perform the NTLM authentication with the server.

I hope this information helps you.
Reymarx Gereda [MSFT]
Reymarx Gereda
Whilst NegotiateStream is able to perform NTLM authentication, there's no indication that it is able to perform NTLM authentication used by HTTP servers/proxies.

The underlying issue I'm trying to address here is that the FtpWebRequest does not support the full range of FTP methods when going via an HTTP proxy. If it took advantage of the exact same functionality used by HttpWebRequest when it tunnels through proxies using CONNECT in order to establish HTTPS connections, it would be able to support the full range of FTP methods providing the FTP server supported passive mode.

I'm uncertain why it was chosen to omit this very useful functionality which, given that the CONNECT proxy tunnelling code already exists should not have been difficult to implement.
cosborne

While NegotiateStream can perform NTLM authentication, it does not expose the handshakes to the caller, so that you can use it's tokens to set the WWW-Authenticate header and talk to the HTTP proxy for authentication.

I think what you really want is an FTP proxy, that supports all the FTP methods that you need. If you have control over the network environment you are operating in, you might have them install a Firewall that opens port 21 outbound so that you can do a direct FtpWebRequest with the destination through the proxy.

For eg, you could install an ISA server, and then use a ISA Firewall client on your client PC, which will tunnel your FTP requests through the ISA server directly to the destination FTP server on port 21.

As an aside, which FTP method are you trying to use?

Hope that helps.


feroze
--
My blog
Feroze Daud

You can use google to search for other answers

Custom Search

More Threads

• Exchange SMTP .NET email issue.
• Mikrotik Bandwdth teste application
• Very strange HTTP behaviour
• Why can't I see the global cloud?
• Setting up port forwarding with nat, using library NATUPNPLib, Null reference exception
• How to Find Unique IP
• check network path
• Post file ?
• FTP in .NET, get list of only subfolders or only files
• Only one usage of each socket address (protocol/network address/port) is normally permitted