If using Sparkle with DataSnap, Sparkle adds a dependency on libapr DLL and that has more DLL's required and so on. But if it was used for IIS ISAPI support exclusively, there's no Apache present and so the DLL would not load.
But saying "using Sparkle with DataSnap" are you actually referring to using Sparkle with WebBroker?
Sparkle in WebBroker supports Apache only. IIS is not supported, mainly because it's not needed, to use on Windows, we recommend simply using the http.sys-based server.
Wagner, in "XData from ISAPI/CGI - #4 by wlandgraf" you have suggested it yourself. And it all kind of hooks together nicely, so I'd expect this to work when I progress to testing it. I just don't want to ship ~15 Apache DLL's with it for no reason.
And MS warns that "HTTP.sys isn't compatible with the ASP.NET Core Module and can't be used with IIS or IIS Express.", therefore there may be compatibility issues there.
In my scenario, I also intend to run this on a Plesk-managed server, which offers full remote management for IIS, as well as setting up free Let's Encrypt certificate and automatically renewing it every 3 months - this latter is my main reason to use this IIS setup and not http.sys. If I can reproduce it with TMS components, I will certainly try. Are there any provisions for this in Sparkle framework?
It actually did not work:
Internal Application Error
Unsupported Web Broker Adapter
Is this officially a deadend for DataSnap/ISAPI/Sparkle support, or could I just still be missing something?
I do some logging, so I can see the WebModule1DefaultHandlerAction firing Ok in DataSnap, but then I do this, as it was suggested in the post I was referring to earlier:
Adapter := TWebBrokerAdapter.Create(Request, Response);
Server.DispatchRequest(Adapter);
And that must be where this error is raised.
Ah, I see:
unit Sparkle.WebBroker.Adapter;
interface
{$IFDEF MSWINDOWS}
{.$DEFINE USE_ISAPI}
{$ENDIF}
uses
[...]
It's commented out. I'll try defining it and re-testing...
Ok, once USE_ISAPI was defined, it does not error out any longer. But my components are not connected: in a http.sys application, where you would have Sparkle things sitting on a form, everything automatically connects and you do not have to call RegisterModule. Here, where Sparkle is created dynamically, but all the other components are on the form, two main questions are:
- How do I register all them? - I have SphinxServer, XDataServer and Aurelius components on the DataModule form (actually WebModule under DataSnap).
- And since it's a DataSnap/ISAPI project, what are the resulting URL's going to be like? - DataSnap has its own DSContext path set at the Dispatcher level ("datasnap/" by default), which may apply, then some TMS components have BaseUrl, but in this setup I do not think they play any role. And my base URL would end with "dll". So, if I have Swagger enabled, what would the final URL be to access it? So far, I'm getting 404 from this server with the URL's I tried...
You don't need to do that. Create http.sys-based servers, it's a much better approach.
What is the relevance? You are using Delphi, not ASP.NET.
You can do that with http.sys as well: TMS Software | Blog
I'm not sure why you refer to DataSnap. DataSnap it's a framework for building REST servers. You don't need it, if you are using Sparkle and XData.
With Sparkle you build REST API servers using http.sys-based servers, the recommended and best way to create API servers for Windows
For Linux, you can use it with WebBroker Apache Modules, or Indy. I'd still recommend using Indy and put a robust reverse proxy in front of it (Nginx, Traefik).
Indy can also be used for Windows, in case you have very specific needs for it - I can't think of any right now, though.
Other WebBroker alternatives, like Indy or ISAPI, are not supported.
IIS offers a lot of extra functionality. And on existing IIS servers, where you do not want any disruption, adding extra http.sys servers could be risky. Using extra products and setting up extra steps for something that happens in IIS on its own is a hassle I'd like to avoid. In Delphi terminology it's called "DataSnap WebBroker Server", so I was using DataSnap and WebBroker interchangeably, perhaps incorrectly. Besides, the support infrastructure seems almost all there for ISAPI, so it would be nice if you could do the last few steps to iron it out and make it available...
Wagner, trying to assess possible problems in advance and not finding a lot on the WEB, maybe you can help, please? - With http.sys, can I run it on my webhosting machine, alongside a number of IIS-run / Plesk-managed websites, without interfering with the rest of the setup / IIS? I really do not want to kill it by accident.
I’m thinking a scenario, where I have domain.com set up with Plesk under IIS, which would also automatically maintain a wildcard SSL certificate, then if I create a reservation for http.sys as https://app.domain.com, where “app” would essentially be a hostname, defined in DNS, then 1) would IIS intercept it, or would it actually go to the http.sys IW application server? And 2) would http.sys automatically find and use the existing Certificate, already installed here for *.domain.com and when that’s automatically updated later on by Plesk, see the new one immediately and transparently? Or would I have to do something about the certificate manually?
Yes. Unless, of course, you try to run a http.sys-based server on an URL/port that is already being used by some of the other services.
It depends on what you have configured in the IIS. The certificate itself doesn't "handle" the requests, i.e., the fact you have a wildcard certificate in IIS doesn't mean much, it only means that if and when IIS receives a request on that domain, it can use the certificate to encrypt the communication.
But once you define in http.sys that you want to listen to https://app.domain.com/myapi, any request going to that address will be handled by the http.sys server, unless of course you have other servers (even in IIS) configured for THAT URL with higher property (for example, more specific URL like https://app.domain.com/myapi/subapi
Maybe. I don't know how such certificate was configured in IIS. But all this is done at Windows level, actually IIS does run on http.sys under the hood, so in the end everything is more or less the same thing when it comes to such kind of configuration.