stijnsanders

I've been using WinSCP to perform SFTP where I needed it. The software runs on servers under my control, so it's no problem to have WinSCP installed there. If you call CreateProcess on WinSCP.com with the /nointeractiveinput and the correct command line parameters, you can have a series of command complete and give predictable output you can process.

I've given this quite some thought. I've made a list once here (it's in Dutch though) what you should do if you want a full fledged account management platform with login, and that's even before GDPR, and not handling what's available from other platforms, e.g. with OAuth or identity services from cloud providers that are available nowadays. I haven't worked with IntraWeb or TMS Web Core, but I've dabbled with a Delphi-(compiler-)based web-platform of my own, with an explicit emphasis on speed, security and portaility (between hosting environments), so yes if you want to build something serious you need user control and it takes some work. For a first big xxm application/website of my own: tx I for now stick to this list I created of everything I think a website with user accounts should have. But for new websites it's increasingly interesting to skip the hard work and make your website depend on a number of options you can expect your users to have an account with: Google, Facebook, Twitter, Microsoft, and if your public is somewhat tech savvy Github. (I should check if reddit has an OAuth api...)

Ah, well here's the interesting thing... Google, who started QUIC as a HTTP/3 proposed successor, kind-of passed it on to that standards body (is it WHATWG? or W3C, I forget en should look it up), and there it kind of took a turn so that QUIC would be more of a kind of like a successor to TCP+TLS but not really but yes really, especially to have HTTP over QUIC instead of TCP+TLS, and have that be HTTP/3 so that you would still have multiplexed streams, but the multiplexing is really done by the layer that does the packet re-ordering that was previously locked in the TCP protocol... So a QUIC library in Delphi? Yes I would like that, but it's quite a big task: it requires crypto by design, sadly enough, so yes it would be nice to see that in future OpenSSL/LibreSSL releases, especially because I've also read that there are parts of the congestion avoidance algorithms that are easy to get wrong or lingering bugs with, as you would need to test them on elaborate networking laboratory set-ups to have then duty-tested and benchmarked... let alone certified for fitness for production... So I'm willing to wait a little.

If anyone cares to try another alternative, I've created my own JSON handler, based on work I had done before to handle BSON for a rough-and-raw handler for MongoDB: https://github.com/stijnsanders/jsonDoc#jsondoc I really dislike long lists of overloads, so it extensively uses Delphi's own Variant type. It also tries to prevent too much allocation of Variant instances. If you need to process identical or similar JSON objects in sequence, re-use the same instance to re-use the allocated keys and values.

Do you have a virusscanner or other protective software active? I've known to have it interferes with installs before.

For what it's worth, going by the little I know about parsers, I guess the parser just takes any list of modifiers after the method signature, and sets the flags on the method. I guess "static" doesn't throw an error if the "static" internal flag was already set, so I agree it's quite harmless.

I have an alternative implementation here, it is build with the larger xxm project, which is primarily designed to be a 'generic' layer between IIS, Apache https, CGI or SCGI, and provides a way to use the very same binary with any of these. Regretfully, not all environments (and their xxm handler) support websockets. xxm has a bare-bones HTTP service as well which till now offers the best performance (but no TLS, compression or even logging...) if you specifically want to work with websockets, see the example project here also.

Have you considered the OnIdle event on tApplication? (optionally with the ApplicationEvents component)? In other words, instead of using a kind of timer, you can have the message pump itself run something between each message! I've had a scenario once that would make the process take 100% of one CPU, but I've recently discovered Windows' own SwitchToThread to have a kind-of timer using Windows' own task switching 'cadence'. If you need finer grained timing, I would suggest QueryPerformanceTimer

Ah well, IIS does its own thread management, that's right. And you have a choice: You could do all the work for a request in the HttpExtensionProc call you get and return HSE_STATUS_SUCCESS, it works really great for small responses and when it's pretty clear what the extension is supposed to do, and each request won't take too much time of a worker process. But, if you want do have more control over threads, over different kinds of things happening depending on the requests that come in, and especially keep threads free when they're waiting on other processes, the best you can do is return rightaway with HSE_STATUS_PENDING, and manage the threads to do the heavy lifting yourself. The threads IIS uses to call your HttpExtensionProc, aren't supposed to run for long times, and probably are also limited in number and will cause 503 errors when they're all occupied. If you want to keep IIS responsive and have more control what happens when a really big stream of requests is hammering the server, I strongly suggest HSE_STATUS_PENDING. Well, actually, I would suggest you try some other options as well. I've been working with something one level down: HTTPAPI. There's a little thing called http.sys which (modern) IIS uses itself to do the actual requests. And the API is open for us to use as well. If you're sure you actually don't need much of the overhead IIS offers (strong security, filters, access control, logging, etc.) or are confident you can do it (better?) yourself, check it out. Also there are open-source alternatives to web servers as well. And there's much more than Apache httpd out there if you care to look. (Yes, done that) I've been able to do CGI and SGI with some of them, but not FastCGI (yet?) mainly because I really dislike how the protocol was designed. NginX is making a great name for itself as a server that's particularly fit to configure for heavy loads. And I've also played around a bit with Lighttpd. And — if you really, really — feel fit for the challenge, you could always try to roll your own. I've gotten the best of heavy load results with that, but that really is eliminating overhead done to the max. (And also I haven't been able to put much time into that project since a while before HTTP v2 is out, and HTTP v3 is around the corner...)

I would consider setting this to 0. Unless you're sure you want your web service to halt when there are a lot of people at once, which seems like the very thing you'd like to avoid. In the work I've done with ISAPI (not using Delphi's own TISAPIApplication though, sorry) I just keep queueing incoming requests in a queue the thread-pool can take from with any worker thread that happens to be available for work... (Though I seem to have written a comment there to consider doing something when there's a lot of incoming requests...) The rationale would be that other things would fail first before your thing does: memory runs out, or network sockets run out, or IIS runs out of execution contexts (and throws 503 itself when it deems appropriate...

I really like PT Mono, but that's just a personal preference.

Could this be due to a setting of isolation level on this client? I remember when you had to switch between named pipes and TCP to get the connection working, there's a lot of other settings you can tweak and change. Perhaps there's one that is causing this.

If the Visual Studio project has a .h file with the same function declarations as the DLL, you should try Dr Bob's HeadConv or a more modern alternative if you can find one.

Are you sure? Process Explorer can kill a selected thread... If you want to do it programmatically, there's either straight-forward ways given you have the required privileges, but I've also seen code somewhere where you declare your process as a debugger for another process that gives you access to interrupting (and then no longer resuming it), but that's quite involved.

I've stopped using WinInet and use XMLHTTP or ServerXMLHTTP classes from an imported MSXML2_TLB (without wrappers), mainly because MSXML2 has gotten a lot of security updates and involves less code to do the exact same as your code snippet. Older Windows versions don't support TLS 1.3, so chances are those computers may really be unable to contact certain websites over https. If you really have to make the web-call, I would advice to look into curl. Either vind a libcurl DLL that works, or package curl.exe and call it yourself using CreateProcess.

You're not showing us enough code, so we're not sure what you're trying to do. The <meta> tag you're supposed to use is <meta charset=""> not content. It also can only be either "iso-8859-1" or "iso-8859-8", you can't offer a combination there. What you can do is use "utf-8" or "utf-16" and be asured that the TStringStream you're building is written using the correct encoding, but we can only check if that's done right if you show us more code.

tl;dr: It specifically mentions COBOL and Delphi as other dying languages alongside Perl, plots their decending popularity curve into the future, Delphi hits 0 a few months before Perl 😿, (COBOL years after...)

Just to get to know MongoDB and what it's about, I once started the hard way and created a really bare-bones just-the-essentials connector to MongoDB: http://github.com/stijnsanders/TMongoWire So, no, I'm afraid the plain MongoDB isn't quite fit for embedding. A basic install would require a basic mongoDB installation alongside with your software. What you could do depending on what you would need from the data-component, is store your own list of JSON documents indexed by their "id" value... But that won't allow you to do clever queries like mongo has with the "$" prefixed query fields...

I've heard about projects that would use Delphi for all user-facing interfaces like forms and configuration tools, but have all the deep-down stuff done by DLL's written in C++ that the Delphi front-end uses to make stuff work.

Would you like to share some code? From what I learned about isapi from making xxm, it's important to catch any and all exceptions in your code, and not have them pass through into IIS as it can't properly handle Delphi exceptions and indeed may terminate the worker process. Typically you have a try except inside of every callback handler, the except clauses set an appropriate return value, but never re-raises, perhaps writes to an extra log.

Just to be able to support TLS without the need for extra DLL's, I've used Windows' own 'SChannel' for a project once here.

Hmm, yes if it's static content, there would be sense in keeping a cache of the gzipped-data somewhere and serve that on subsequent requests. If it's dynamic content on the other hand, you might suspect this data to be one-off specifically for each request. So if there's a lot of it (and might take some time to generate, typically longer than it takes to transmit over to the client...) and you're having transfer-encoding chunked (which enables keeping the connection open when the response is sent over) then you should use TZCompressionStream's capability to zip a next chunk based on the existing stream...

Does MARS do streaming? Or does MARS do transfer-encoding chunked? (If so, you're apparently supposed to gzip first and then do the chunking...)

I remember Windows introduced manifest resources into exe files at some version and they also control the mapping to one of the versions of comctrl.dll that is present in the system. Could a manually modified .manifest file be causing this problem?

I've been dabbling on a JSON parser that accepts pascal strings, and "=" instead of ":", and allows missing ","... https://github.com/stijnsanders/jsonDoc