Re: cvs commit: apache-1.3/src/main http_config.c http_core.c http_protocol.c

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

>>   Fixed request limit change to be more portable.  Removed the server_rec
>>   variables since compile-time control of the request-line, fieldsize, and
>>   number of fields is sufficient.
>
>No time to really comment in detail, but I disagree with the above in
>principle.  We getting a *lot* of people using prepackaged binaries
>(RedHat, FreeBSD, ...), and making them recompile seems unfriendly.
>I'd much rather see run-time directives available for these.

We just had this discussion yesterday, and now everybody changes
their minds?

It doesn't make sense to allow people not compiling the server to
change values that they need an understanding of the protocol and
source code just to get right.  There is really no advantage to
allowing a person to artificially shrink those values, and I am far
too paranoid to allow them to fool with actual input buffer sizes.
So -1 on that idea for the request-line and fieldsize limits.

If you really want a configurable limit for number of fields,
go ahead.  It has to be a per-server config since it is used
before virtual-host/directory/location walks occur.

....Roy

Re: cvs commit: apache-1.3/src/main http_config.c http_core.c http_protocol.c

[Dean Gaudet <dg...@arctic.org>]

On Mon, 10 Aug 1998, Dean Gaudet wrote:

> -1 on your limit patch then, as it removes functionality from the server
> and does not provide an alternative workaround that is compatible with
> predistributed binaries.
  ^^^^^
  precompiled

And I am serious.  I really think it is in our interest to never have to
tell people "recompile with -DFOOBAR".  The server, out of the box, should
let you change as much as possible.  This is a trivial thing to allow
folks to change.  If folks set them too low, then that's their own
problem.  They could have equally well shot themselves by using a "limit
datasize".

Dean

Re: cvs commit: apache-1.3/src/main http_config.c http_core.c http_protocol.c

[Dean Gaudet <dg...@arctic.org>]

On Mon, 10 Aug 1998, Roy T. Fielding wrote:

> We just had this discussion yesterday, and now everybody changes
> their minds?

I don't recall discussing this.  I certainly never said anything either
way about run-time configurable limits.

> It doesn't make sense to allow people not compiling the server to
> change values that they need an understanding of the protocol and
> source code just to get right.  There is really no advantage to
> allowing a person to artificially shrink those values, and I am far
> too paranoid to allow them to fool with actual input buffer sizes.
> So -1 on that idea for the request-line and fieldsize limits.

-1 on your limit patch then, as it removes functionality from the server
and does not provide an alternative workaround that is compatible with
predistributed binaries.

I would be +1 on run-time configurable directives that have a minimum
setting.

> If you really want a configurable limit for number of fields,
> go ahead.  It has to be a per-server config since it is used
> before virtual-host/directory/location walks occur.

Right.

Dean