On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 16.06.2005 um 22:13 schrieb Stephen Deasey: > > > > > At any time before the registered proc asks for the content it can > > check the content length header and decide whether it is too large to > > accept. You could imagine setting a low global maxinput, and a call > > such as Ns_ConnSetMaxInput() which a registered proc could call to > > increase the limit for that connection only. The advantage over the > > limits scheme in 4.1 is that the code which checks the size of the > > content and processes it is kept together, rather than having to > > pre-decalare maxinput sizes for arbitrary URLs in the config file. > > > > > Aha... do: > > ns_conn setmaxinput > > before we do > > ns_conn content > > to get the content of the request. > > Hm... so we'd keep the maxinput reasonably *small* for most > of the requests and will re-set it to a larger value *before* > requesting the content when we anticipate large file upload. > > I think I'm beginning to understand.... > Yes, this makes sense.
Yes, that's the idea. I mentioned it because 4.1 introduces a new 'limits' mechanism to deal with this, and as we're looking at different implementations to decide what to do, I thought I'd compare the two strategies. Nothing stops us from also implementing limits. But with 4.1 where the request body is read eagerly and spilled to disk via the driver thread, the *only* way to set the maxinput on a per-URL as opposed to per-server basis is to preregister this limits data. With the scheme we're describing here, we can use a more natural, linear programming style to set the limit before asking for the data.
