>
> > 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??
Nothing in the HTTP protocol spec puts a limit on the number of HTTP request/response
pairs that can
flow over a connection. Well implemented HTTP Servers allow the sys admin to impose a
limit on the
number of requests the server will server on a connection (e.g.,
MaxKeepAliveRequests). Why? To
keep a client (browser) from hogging all the resources at the server. In other words,
to give all
clients 'fair' access to the server resources.
>
> > 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.
That's hardly an argument to support multiprotocol routing...
> > 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?? :-)))
Build it and they will come? Not a good business model IMHO, but it sometimes works
in movies :-)
Seriously, have you any hard requirements from any application that is 1/100th as
important as the
HTTP Server? Our primary "customers" are HTTP server users. Let's make them happy
first and quite
trying to solve all the network server problems of the world, else we'll end up doing
everything
half assed.
Bill
