> OK, I was not at the HACKATON, but 'keepalive' is an HTTP
> specific protocol mechanism. If not, please refer me to some
> protocol that uses it?? :-))
keepalive as a name is used in many protocols, including TCP. The specific
function of those two variables is used by ANY server that places a limit
on requests per connection. It is not even remotely specific to HTTP.
The only Internet app protocol that I know of which would not use such a
limit is TELNET.
> With respect to moving HTTP specific variables out of the core
> I would follow my above statement. But as I understood
> keepalive is maybe HTTP protocol specific it is to much spread
> over Apache core code which makes the move difficult.
>
> Although, naming is not a real issue in my opinion.
> Would it not be an option to name it like 'keepconnection'??
> That means other protocols (and thus their module implementing it)
> that expect multiple requests over the same connection. However,
> this would extends the semantics a bit. Even though, you keep
> it as keepalive for HTTP.
As I said, the name can be changed, though I'll repeat that "Keep Alive"
is the common generic term for keeping a connection open for more than
one request. It is not HTTP specific. The only thing HTTP specific about
that code is the comments above the variable.
> > There are no limitations on requests per connection defined by HTTP.
> > It is a common tool to avoid denial-of-service (or, more accurately,
> > enforce fairness-of-service) at the application-layer.
>
> I am not sure what you mean here. Is "Limit" not designed for this??
> Or do you think of other limitation functionality??
>
> > Third, I see no reason to make the Apache httpd code base generic to
> > all protocols. If done at all, this work belongs in a different tree.
>
> Roy, but why are there now claims made Apache is capable of doing
> multiple protocols. I envision that protocol module would only
> make use of "ap_hook_process_connection" like mod_echo does.
> For the rest it does whatever it wants itself.
There are claims of it being multiprotocol because that was of the original
design goals that Robert Thau had for 2.0. By multiprotocol, he meant
HTTP and HTTPng (the original binary HTTP over SCP spec by Simon).
Multiprotocol does not mean every protocol under the sun.
> > I understand why it would be nice to have a multiprotocol routing core,
> > but the current code base is nowhere near efficient enough to support
> > such a change, certainly not without some justification from real users
> > that need such a beast. We need to concentrate on getting it that way
> > for at least SSL and HTTP.
>
> Would it not be possible that there are no users, since there is
> nothing (multiprotocol Apache) to use?? :-)))
No. A server is supposed to be simple. The only reason to have multiple
protocols within a single server is if you have multiple potential
protocols on the same port. That is why SSL, HTTP, HTTPng, SOAP, and
waka are all candidates for a multi-protocol httpd, whereas FTP and IMAP
and BXXP are not. That doesn't mean that someone can't use the Apache
software to create servers that handle those other protocols -- it only
means that the code doesn't belong in httpd.
I have no objections to starting a sandbox for a multiprotocol framework
that, once it proves to be better, can be adopted by the httpd project.
But it doesn't make any sense to do that in httpd-2.0, just as it didn't
make any sense to create APR within the main development tree.
....Roy
