httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: cvs commit: apache-1.3/src/main http_config.c http_protocol.
Date Sun, 09 Aug 1998 22:25:10 GMT
>> What, exactly, is silly about limiting the request body size?
>Because if someone uses request bodies for something useful then having a
>fixed, unconfigurable limit at something like 32 megs is horribly broken.

We don't do either, so that's just hypothetical.  All other Internet
servers (FTP, SMTP, etc.) allow the admin to set limits on incoming data
to prevent disk overloads and denial of service attacks.  I figured
32megs would be plenty, but that's why I asked for input on the values.
ULONG_MAX is 4GB, so anything up to that is okay with me.  We can also
do what Jim suggested and have 0 mean unlimited.  Actually, the body
size limit should be directory configurable -- it's only the other
limits that need to be known before the URL is parsed.

>Because, while the number of header fields, size of them, etc. are
>generally reasonably independent (given currently defined HTTP headers and
>use of them) of what you are doing, the request body size can vary a huge
>amount.  Something as simple as using PUT to send a 40 meg file (which
>seems like a resaonable thing to me) would run afoul of this limit.  It is
>only mildly annoying if it is configurable, but if it is a fixed
>compile-time thing as was suggested, then it becomes lame.

I don't run a server that would ever use more than 8KB in a body, at least
not until we implement PUT and WebDAV.  File upload was the reason for
the 32meg limit.

>Oh, why were the DEFAULT_LIMIT_* defines added to httpd.h _after_ the
>section where things like that are stored instead of with all the other
>config type constants?

I looked through httpd.h for the most natural place that wouldn't cut
between related defines.  That's where I put it.  We don't have a special
section for config type constants.  I'm all for creating one, but don't
mix cleanups with changes.


View raw message