Maybe I'm not searching for the correct terms, or maybe this is not something that people usually care about but I simply cannot find out how to get the TCP Port the Client is connecting from.
I have a client that uses a TWebBrowser and an Apache server that has a Delphi WebModule running. The client connects to the URL on port 80 and somewhere in this I need to report on the port that client is using.
At the WebModule end I can collect the IP address of the incoming connection (Request.RemoteAddr) and any variables it sends in a POST body, but I cannot seem to get the port it is originating from.
I have found some explanation of this using Indy but nothing that has helped me to implement something useful at either the client or server end. I'm not sure where to go from here so any suggestions would be welcome.
Sadly, TWebRequest simply does not expose the client's port, or access to the underlying request/socket needed so you can obtain the client's port manually.
This is a limitation of WebBroker itself, not of Indy (which is one of the available backends that WebBroker can use, via Indy's IdHTTPWebBrowserBridge unit. Indy has access to the client port, but you don't have access to the Indy HTTP server that WebBrowker uses internally).
Related
The website of our company is running on IIS 7.5, recently and without any modifications in the configuration, the website start to give us the error 404, here is a picture of the error :
the website work fine with HTTPS and HTTP on every port except the port 80, and we have never used MorMot
Do you have any ideas where this problem comes from ?
There is a registration mechanism for URI on Windows, when using http.sys. It is a kernel/system component, handling HTTP/HTTPS requests.
This registration is shared by IIS and other programs using http.sys, like WCF or mORMot projects.
From the HTML returned, there is clearly a mORMot-powered executable running on the server, which is bound to port 80. You have to identify this program and fix its configuration, to use another port or another sub-URI on port 80, to share it with IIS.
One big benefit of http.sys - in addition to its performance - is that you can share URIs on the same (sub)domain between executables, but you need to register the sub-URI. This is a standard mechanism under Windows - please check this reference page for instance.
Another possibility may be to use IIS as reverse proxy, and run the mORMot-powered executable on a local non-routed port, if you have troubles with http.sys configuration (which is not easy).
My application consists of a 'gateway' DataSnap REST server that is the first point of access for all clients. Depending on the username the clients pass in their requests (basic authentication), the request needs to be redirected to another DataSnap server. My question - is there anyway of building the 'gateway' server so that it simply redirects whatever the request is to another server based on the username, or other values in the HTTP request headers? I'm trying to avoid having to repeat all the server methods in the 'gateway' service i.e. I'd rather not 'chain' 2 requests together but somehow just have 1 request redirected.
Not sure if this is possible, but thought somebody might prove me wrong? I'm using Delphi XE2 and the DataSnap servers are Windows services.
I can see two options here:
use the first server only to return the address of the real server after logging in
or
use a Apache or NGINX reverse proxy in front of the Datasnap servers and RewriteRules based on the authentication data (however my Google-Fu for today seems to be exhausted, maybe this can be placed as a HTTP / Apache specfifc question here on SO)
Short version: the solution will depend on which level (HTTP, DataSnap, in between) you know where to target the request to.
If you can make the decision on the DataSnap level, there are two kinds of solutions:
The purists way to do this is write a generic DataSnap gateway that can interrogate a datasnap target server, dynamically creates both a proxy server and client for it, then intercepts the traffic and decides which datasnap target server to hand over the request to.
A more pragmatic approach would be the one you are afraid of.
Another approach would be on the HTTP level. That will only work if you can determine at the HTTP level to which target server a request should be handed over to.
Long ago I started some "web applications" using Delphi 2007 and WebBroker (TWebModule). At the time I assumed you needed a webserver such as Apache or Microsoft IIS in order to create any sort of website. Additionally I don't use most of the Apache features (except for Virtual Server so I can have multiple domains on a single ip address and SSL). So to me Apache is just an extra layer and makes makes debugging difficult.
Now enter Indy (TIdHTTPServer). If I understand correctly, Indy IS a webserver. So by using Indy I am no longer bound to use Apache or some other webserver. Is this correct?
Will I have any issues supporting the Virtual Servers in an Indy environment? And what about SSL. I have searched the literature and from what I can see it fully supports SSL certificates.
I am now in the process of porting some of my application from WebBroker to Indy. This mostly entails replacing within my code references of Request: TWebRequest with ARequestInfo: TIdHTTPRequestInfo and references to Response: TWebResponse with AResponseInfo: TIdHTTPResponseInfo.
Is there anyway to use the TWebModule architecture within Indy so that I don't need to do all of this rewriting?
Lastly is there anything else I need to be concerned with? My goal is to take Apache out of the loop.
Yes, you can use Indy's TidHTTPServer as a webserver, but it's much lower-level than IIS or Apache. There is no concept of virtual servers - this you would have to implement yourself.
Indy does support SSL as well via the OpenSSL dll's.
I imagine the biggest concerns you will have will be security related...there are millions and millions of sites running Apache or IIS and there are a ton of people devoted to finding flaws in those platforms, with a bunch of people fixing some of those flaws as they come up. Not so with Indy... there's one or two guys that respond on newsgroups to bugs that you discover. (One guy in particular, who will probably respond to your question here as well.)
Now, I use Indy HTTP server (along with SecureBlackBox SSL support) and I find it to be great for my purposes.
Indy HTTP server calls the WinSock API, and is able to implement:
A full HTTP/1.1 server;
A full HTTPS server (using either OpenSSL libraries or other third parties, like SecureBlackBox).
AFAIK you can use Indy to publish web modules.
See http://www.2p.cz/files/2p.cz/downloads/howto/indy_soap_web_services_in_delphi.pdf
You can also use other servers, for instance directly the kernel-mode http.sys server, which is used by ISS and .Net WCF for instance, and known to be very stable and efficient (it bypasses the WinSock APIs). Of course, it will serve HTTPS conent, if needed. It is available in standard since Windows XP SP2, and therefore in Vista and Seven. Using this component will let Microsoft will do all the debugging work for you, and it will be updated with the host OS. I use it for instance in our Client-Server ORM, or directly to replace a deprecated DCOM connection, with very good speed and stability on customer side.
Regarding virtual servers - the HTTP 1.1 spec requires clients to send a Host request header so virtual servers know which domain is being used specifically to handle the case when multiple domains have the same IP. TIdHTTPRequestInfo has a Host property for that value. In fact, TIdHTTPServer internally validates to makes sure that an HTTP 1.1 request has the Host header before firing any of its OnCommand... events.
Is it possible to convert Delphi SoapServer application to use TCP/IP?
From your comment to your question it sounds like you are looking to get rid of SOAP, and use something else to communicatie over a TCP/IP connection.
The question one could ask is why do you want to convert to non-SOAP comm over TCP/IP?
But the answer to whether it is possible is: of course this is possible, there are many application servers using TCP/IP for communication without using SOAP as their communication's protocol.
You will need some kind of protocol for communication between server and clients. You could roll your own, but doing what SOAP is doing for you now: receiving and responding to commands from clients (or method invocation) and marshalling data/objects between server and clients is not a trivial task.
So I'd suggest you have a look at other remoting libraries for client/server communication, such as:
Remobjects: http://www.remobjects.com/
kbmMW: http://components4developers.com/
As others have said, SOAP is just XML on http/https, and usually does already use TCP.
That said, you could simply treat it as raw socket data or http data. i.e. you could make a client that just uses http POST to send a string to the server. The string would contain an XML SOAP request, and would be treated by the server as if it were SOAP. Likewise, you could build the server in a non-SOAP fashion, just accepting XML and returning XML, and the client wouldn't know the difference.
You can use Fiddler2 to play with this. You can build requests and send them via HTTP Post. The server has no idea that you're not a SOAP client.
Chris
If you're talking about pre-Delphi
2009 DataSnap, meaning COM based
DataSnap, then you have to use a third
layer utility to do the communication.
That utility named sockets.exe is
included with Delphi, and is in the
same dir as Delphi (Program
Files\\\\bin
If it is Delphi 2009 or better, then
DataSnap has built-in TCP/IP
functionality. You use
TDSTCPServerTransporter component.
Update: Ups! for some reason I did read DataSnap SoapServer (wich neither exists, but I did think of Soap Connection).
A Soap Server Application needs the "server" part, meaning a web server. SOAP is an technologie that runs over HTTP protocol, so I don't think it could be "converted".
DataSnap could do the job, or Indy TIdTCPServer or some of the derived classes.
I have a Delphi application that uses ADO to connect to a SQL server hosted on the Internet. The user running this application wants to access the SQL server through a proxy internally. How can this be done?
There is nothing special that needs to be done in the actual application, this is a networking problem, you would have to open some ports (1433 is the default) on the firewall for the communications to go through (going out)