No need to use the rdp protocol in any way
That is, I think, where you run into more problems. In my original reply I focused on the user security aspects of your implied connection, and Pat has mentioned her concerns over that facet as well. However, you should also be aware that there are issues in, for lack of a better term, "control pathways" - i.e. how you pass a user's control and data actions to the Access session. In this reply, it might at times sound like I have retreated to my first post by talking about session security - and to be honest, that IS intertwined with the point I am making here. However, this time the theme is more along
operational lines - how to get data from point A to point C with an intermediary standing in between the two end points AND the two endpoints don't "speak the same language (protocol)."
Access has a graphics-oriented user interface that depends on a particular "connection" mechanism which RDP emulates (a hard-wired or virtual-connection to a Windows interactive session) but that the HTTP/HTML combo does not. Access expects you to pass things to the session like mouse-cursor position, clicks (left and right), and keystrokes. But without an interactive-session interface, Access won't get those things.
RDP works because there IS a session going on behind the scenes there. I.e. Remote Desktop Protocol supports the "session" concept and makes the connections easy. But part of the problem with HTTP is that it is designed with a different KIND of session structure - where your IMPLIED session at the server is managed in part by the HTTP client that looks at your locally stored cookies. The HTTP client has to pass in that cookie data to identify which of several equal sessions are involved at the server side. HTTP is transaction-oriented whereas RDP is session-oriented.
Although Windows was rewritten some time ago (Windows NT was the change-over point), it still has vestiges of the three default channels - IN, OUT, and CMD. Each interactive session (and technically, each batch and each network session) has a separate process (a.k.a. task or session) structure in the O/S scratchpad memory area. Yes, a task can open other channels - but it starts its existence with those three channels by default. This is a holdover from Windows in the MS-DOS era.
Actions can be performed simultaneously for each task up to the number of threads supported by your multi-core system. (My home system happens to have 8 threads, i.e. 4 dual-core CPUs.) Windows architecture was designed in the era of a single-core system that did time-sharing via time-slicing multi-task environments. The transition to multi-CPU time-sharing became trivial because of O/S-level tricks, but I won't try to open THAT can of worms right now. And it is irrelevant to this discussion.
By contrast with RDP, the HTTP server-side task linearizes inbound HTTP client transactions from multiple sources, all in the same session, which it can do because the cookie data (passed along with the actual request data) tells the server which transaction thread it is currently processing. You know how a site lets you tailor your cookie preferences? The "Necessary" cookies are the ones that manage the implied-session data.
Yes, you CAN have multi-core involvement here too, but there it doesn't matter which core does what to whom because each transaction contains its own ID. The RDP approach, however, knows the user ID because it was associated intimately with the private session when that session was first created. Private sessions don't need to verify the ID every time because only one user can use the virtual connection for the lifetime of the session. And at this point, my discussion about user security in my prior long post becomes relevant so I won't repeat that here.
