We Keep Coding

HttpListenerRequest.Url when port forwarding

I have simple http server based on HttpListener. Http server is running on local machine (IP: X.X.X.X:10101) behind the firewall. To make Http server visible for external request i have added port forwarding on firewall from external interface Y.Y.Y.Y:8080 to X.X.X.X:10101.
Now: When i receive request from external host i see that HttpListenerRequest.Url is set to Y.Y.Y.Y:10101 - so its kind of mix between internal and external interfaces (IP belongs to external interface, and port belongs to internal interface).
What is the reason of this behavior? I would expect that url should be Y.Y.Y.Y:8080. Is there any way to "reslove" original url that request was posted to?
Best Regards,
It Man

I seems that firewall modifies http request header, changing external port to local.

Handle a HTTPS WebSocket handshake in C#

I have a local c# server running and listening on localhost and a browser connecting to a cloud service running a JavaScript HTML5 implementation of websockets. Standard ws://
This works great over HTTP:// and I can read the header and use it, but I need it to run in HTTPS:// I understand that I have to change to wss:// and this does connect to my server but the header is garbled/encrypted.
I have looked into SslStream but drawn a blank.
How do I handle this WebSocket Secure header in C#?

This question was answered in the comments:
If your app is behind a Proxy load balancer, it would normally manage the SSL for you (accessing your app without encryption).
If you need to manage SSL, complete the SSL handshake first (usually right after you accept the connection) and than parse protocol specific data (HTTP, Websockets, SMTP etc').

Handle HTTPS Request in Proxy Server by C# ( CONNECT Tunnel )

I'm trying to write a Home Proxy Server in C# and I almost succeeded but I have problem to handle HTTPS requests (CONNECT).
I don't know really how to handle this type of requests.
In my studies I realized that for this requests we must to connect client to target host directly.
Steps for these requests (that I realized):
Receive first request from client (CONNECT https://www.example.ltd:443 HTTP/1.1) and send that to target host
Send HTTP/1.1 200 Connection Established\r\n\r\n to client
Listen to both sockets (client and target host) and send receives from each other to each other
Listen until one of sockets disconnected
Is this correct? If it ok, how handle this by c# ?

My understanding is that the
CONNECT www.example.com:443 HTTP/1.1
from the browser is asking you to establish a connection to example.com on port 443. Once this has been successfully achieved, you should THEN send the
HTTP/1.1 200 Connection established\r\n\r\n
string back to the browser. You do not send the CONNECT string to the server as I think you were doing. Also, this initial connection SHOULD NOT be encrypted.
From this point, the browser and end server will exchange data over the plain text connection which you must forward to the correct destination. To do this, the socket must remain open. However, the order of communication is not specified, so don't rely on the browser sending data followed by a response from server. Either could send data at any point. They will first establish their own secure connection, then begin to do the usual http requests.
Hope this helps.
References:
https://stackoverflow.com/a/24195792/1224132
https://datatracker.ietf.org/doc/html/draft-luotonen-ssl-tunneling-03
http://www.ietf.org/rfc/rfc2817.txt

Relay a request from client to Server via Proxy using sockets c#

I have custom tcp server listening on port 5888(dummy port). The proxy server listens for incoming connections. When the proxy receives a HTTP Request, it should relay the same request to a different server.
Eg:
Proxy receives: http://proxyserver.com/mypage.html
Proxy should Relay: http://MainServer.com/mypage.html
The response from the Main Server should be sent directly to the requesting client.
I have used sockets for accepting connections and parsing the raw HTTP Request before relaying the new HTTP request to the main server. This is becoming too complicated, since I have to send the Raw HTTP Request to the main server, get the response and send it to the client machine.The proxy is basically becoming a middle-man. I want the proxy only for the
one side of communication i.e to change the host address to the MainServer and then the main server should take care of sending the response to the requesting client.
How to achieve this ?

HTTP works over a TCP connection initiated from a client to a server. In presence of proxy you need at least two connections - one from client to the proxy, and one from proxy to the server. These two connections are sort of "independent" in a sense that both transmit standard HTTP requests and responses. Proxy here acts as a client to the end server.
What you want involves at least three TCP connections, and requires sending HTTP response on a different connection from the one where initiating HTTP request came on. That is outside of the HTTP proper - the client wouldn't know that it needs a second connection somewhere else, and how to match requests on one connection to responses on the other. The best you can do within HTTP is redirecting to a different server, say, with a special generated URL or something.
Just remember that HTTP response has to come on the same TCP connection as the original request.

Check proxy type

I'd like to determine whether the proxy at a given IP address is transparent or anonymous. Transparent proxies connect to websites with your real IP in headers like HTTP_X_FORWARDED_FOR or HTTP_VIA. I would like to check these proxies, but all solutions I found are developed to work on server side, to test incoming connections for proxyness. My plan is to make a web request to an example page via the proxy. How do I check the headers sent by the proxy, preferably using the WebRequest class?
EDIT: So is there some free web API that will allow me to do this? I'm not keen on setting up a script on my own small server that will be bombarded with requests.

Simply you don't need that headers. I could check transparency of a proxy by sending request to any get-my-IP site, if it returns my IP then it is transparent. If not then the proxy is anonymous. So steps are:
send request to any get-my-IP site without proxies
extract the IP from response as my local IP address
send new request to any get-my-IP site with the proxy
extract the IP from response and compare it with my local IP (step 2)
if(LocalIp==ProxyIp) then the proxy is transparent else it is anonymous

That is technically impossible since the client only sees what the proxy returns back to the client - the proxy can do whatever it wants when communicating with the target server and transform your request and the answer from the server anyway it wants...
To really know what the proxy does you NEED see what the server gets and sends back without any interference from the proxy...

The reason all solutions are server side is that the headers you're talking about are only passed from the proxy to the server and never back to the client again in the response.
In other words, if you plan to check for HTTP headers in the request from the proxy to the server, you either need to check them server side (as the solutions you found do) or actively pass them right back in the response to the client to check.
Either way, you can't just make a request to a random page and check the headers the server gets, the server needs to be involved in some way.