On Mon, Nov 24, 2008 at 8:18 AM, Thomas Lindgren
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm using mod_perl2. I'd like to reject user requests, e.g., very large
> PUTs, after examining headers and authorizing the user, but before the
> request body is read. Quota checking could be an example of where this is
> useful.
>
> However, at this time, even if I return an error in the handler, it
> (surprisingly) seems as if the request body still is uploaded. What to do?
I don't think that partial uploads are supported in the HTTP spec.
I'd suggest an inputfilter like Adam said, and maybe close the
connection if the request isn't what you want. A bit of a hack like
you said, but it should work if your client is aware of it.
>
> Here is a boiled-down config, which just returns an error code after reading
> the header. In the real code, I also examine the headers a bit before
> deciding, but here I'm just interested in the case when the request is
> rejected. The example below uses the HeaderParser hook, but the same things
> seems to happen with a Fixup handler.
>
> ...
> <Location /test>
> PerlHeaderParserHandler Test::Reject
> </Location>
>
> The handler itself just returns an error code:
>
> ...
> sub handler {
> my $r = shift;
> return Apache2::Const::HTTP_INSUFFICIENT_STORAGE;
> }
>
> Running a big PUT to $SERVER with curl transfers the body anyway (but then
> returns the error):
>
> # curl -o put.txt --basic --user a:b -T example.vmdk
> 'http://$SERVER/test/foo.vmdk'
> % Total % Received % Xferd Average Speed Time Time Time
> Current
> Dload Upload Total Spent Left
> Speed
> 4 2743M 0 0 4 123M 0 9185k 0:05:05 0:00:13 0:04:52
> 10.4M^C
>
> The only way to trigger an early close so far has been to die in the
> handler, which confuses clients and so on.
>
> The server could as a worst case alternative actually close the socket, but
> that feels inelegant and hackish. So, my question to the esteemed list, how
> should this sort of thing best be done? Have I forgotten something basic?
> Should I return something else? Is there a more appropriate phase to do
> this? Should I do it another way entirely?
>
> Best,
> Thomas
>
>
