Hi Alex, > And it *is* an error if a client tries to access a non-existing > application.
I would not blame the user for causing an error if she was unfortunate enough that her session expired and the process handling her session terminated. The user did not do anything wrong, it can only be the developer's fault for limiting the system this way. >> 2) use 'void' and display a page which is "broken" (no way to link to >> the correct app start page) > > It is not "broken". It does what it is supposed to do: Display an error > message. Everything else, like printing "Timeout", or assuming where > the user should be connected, are conceptual extensions which I don't > want to be coded into 'httpGate' or the server itself. For the use case above, it means displaying an error message when the developer "caused" an error, not the user. From the user's point of view, there is no error and no error message should be shown to her. She could be informed what happened (that the system decided to do something against her will), the system should apologize to her for treating her badly and she should be offered a reasonably user friendly solution to that situation. > That's all that 'httpGate' knows. The 'void' link is just a local > addition, to allow 'httpGate' to display a customized error page. Error page for something which is not an error? I think httpGate is trying to be too "local", it should work in concert with the rest of the picolisp. httpGate introduces a special control branch while httpGate0 is kind of linear in that sense. >> > Timeouts are managed by 'httpGate' and 'void'. The app itself does >> > not know about those concepts. >> >> That's the choice I do not agree with;-) I think httpGate should not >> handle timeouts. > > I did not state it clearly: 'httpGate' knows nothing about timeouts on > the application side. It just detects that it cannot connect to the > local application. The local server also does not know when one of its > child processes (a session) timed out. > >> would say that httpGate prematurely handles timeout with the hardwired >> piece of C code and this limits usability. > > No, the C code does not handle the timeouts we are talking about here. > It uses alarm() internally, to detect a hanging connection to the > client, not the server! This should not be confused with the error page > we are talking about in this thread. We got confussion here because we started talking about expired sessions as timeouts, which I agree is not right. >> I think that the concept of 'void' is complicated and limited. I > > Only because you try to put in more than there is. It just is a > customized error message. It should not be an error message in this case. picolisp should be as simple as possible but not oversimplified... It is better to have something more complicated and correct than simple and broken;-) Even though I think it could be both correct and simple in this case. > Adding a new concept like intelligently reconnecting the user to some > application is nice, but we can add thousands of new concepts to the > core system and lose the "pico" in PicoLisp ;-) User friendlines should not be a new concept:-) And the core system should be general enough to allow for wide class of solutions and not constrain application developers too much I think. In reality, we already have the concept of web applications and their start pages and sessions which are forked by the applications. Why do you think it is better to lack concepts rather than introduce concepts that correspond to reality? >> Also, the error handling in lib/http.l where *CondId <> *SesId and >> *ConId <> NIL is a bit arbitrary, while that case suddenly makes sense >> in the context of httpGate0. > > Because you mix concepts. The session id is there for security reasons, > it does not have the concept of distinguishing an application from > another running on the same host. I might be mixing concepts here from the current implementation point of view. Obviously I feel that the concept of application is missing now as its lack forces me to accept "broken" behaviour of my system, thus the problem I have with current implementation. >> httpGate: if the url is /([0-9]+)/ connect to port $1, if it fails >> display page 'void'. For other urls connect to the default port. > > No: If the url is /([0-9]+)/ connect to that port, otherwise to port $1. > Only if the connect fails and the url seems to contain a session ID, it > tries to display 'void'. Sorry for not being clear, /([0-9]+)/ was meant to be regexp and $1 refered to the number matched in parens. It was not meant to be the default port (the "end" port specified on the command line). > There may not even be a default port $1. In the case of httpGate0, it will fall back to 'void' if there is nothing listening on the default port, so it behaves exactly the same in that case. I dont think the concept of 'void' should be there anyway. >> For the httpGate case, once it fails to connect, it is the end of >> everything, I cannot fix the problem (display a *proper* error or >> timeout page) as the control path is out of any reach and outside my >> system. > > Then a better and generic solution might be that we parse the "Referer:" > field from the HTTP header (in '_htHead'). > > This would be also useful for other purposes, and could be used in the > page pointed to by 'void' to find out the originating application (by > pointing 'void' "home.l" or so, which in turn analyses the referrer). > > What do you think about this? Assuming the referer gets to a picolisp server, how would you determine the correct app starting page from the referer url? Thank you, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
