Hi Tomas, > > so 'httpGate' doesn't have enough information about which application > > the expired port belongs to. This could probably be solved with some > > more bookkeeping. > > > > As far as I can see, your 'nginx' can't handle that either, because it > > doesn't keep track of session ports related to application ports. > > It does address the first step for handling expired sessions. Then of > course as the next step, the application code has a logic to do the > right thing when a session expires (which is not described there).
No, this doesn't answer the question. This is exactly the same as 'httpGate' does. It handles the first step. Instead of the static "Timeout" page, I could display a list of URLs of applications but I didn't find it worth the effort. Your solution also doesn't know, which application to connect to. What is the right thing? If you have 16 PicoLisp servers running, each listening on a different app port, which one does 'nginx' connect to if a session (child process) is no longer running? > > 'httpGate' does have a fallback mechanism, though only to a single > > default page. > > Yes, that is not enough. nginx in my setup is basically a bit better > httpGate, a proxy with better fallback. Why? BTW, 'httpGate' has some other significant advantage: It is in the "spirit" of PicoLisp, for one because it is simple (254 lines of code), but more importantly it follows the local versus global principle. It uses, as opposed to 'nginx', no global configuration file, no environment variables, just the command line. You can start up one or many instances of 'httpGate', completely isolated. And, of course, it handles HTTP/1.1, keeping bi-directional connections open for multiple transactions. This is very performance-critical, especially when using JavaScript components over an encrypted connection. > > Tomas, I'm quite upset about your statement that "the URL handling in > > PicoLisp is broken". This is not the case! It proved to be very > > efficient and useful during more than a decade. > > I'm sorry I upset you:-( Maybe I should have said that the URL handling > is designed for a very specific use-case. I stop now;-) OK :) Cheers, - Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
