> I think httpGate is
> more complicated than httpGate0 and also it is broken in the sense
> that it does not allow to display a *proper* error or timeout page.
I disagree. 'httpGate' should not try to be clever. It should not
connect to the first port by assuming that somebody will handle the
error. And it *is* an error if a client tries to access a non-existing
application. That's all that 'httpGate' knows. The 'void' link is just a
local addition, to allow 'httpGate' to display a customized error page.
> > You need a some management *inside* the application to display a
> > proper error or timeout page.
> Only inside the default server. That's the only way to display a
> *proper* error or timeout page.
It depends on what you consider proper. But I don't want to introduce
more assumptions into the server.
> 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.
> > 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.
> 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.
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 ;-)
> 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.
> 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.
> 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'.
There may not even be a default port $1.
> 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
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?