[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: reading POST data in 404 handler
From:       Elizabeth Mattijsen <liz () xxLINK ! nl>
Date:       1999-04-28 16:30:34
[Download RAW message or body]

At 11:49 4/28/99 -0400, the Rodent of Unusual Size wrote:
>> Would the following be a solution:
>> 1. a PerlFixupHandler or earlier that would internally mark the
>>    connection as non-persistent, thus not causing the request
>>    body be discarded?  I'm not going to send any content-length
>>    in the response header, so keep-alive won't work anyway.
>>    Question: how do you do that?
>In C terms, set r->connection->keepalive = -1.  The problem
>here is that you can't be sure at what point (what phase)
>an arbitrary module may abort the request by returning 404.
>It may occur before your fixup-handler, which obviously won't
>allow you to clear the keepalive state.  Or it might occur
>after your handler -- but what if it's a successful request
>and not a 404?  Then you've needlessly cleared the keepalive
>status.

Yep, a KeepAlive Off in the apache config would then be easier.


>> Or, much hackier:
>> 1. a PerlFixupHandler (or earlier) handler that
>>    would read the request body so far into a global
>>    variable, e.g. $CONTENT
>> 2. overload Apache::Request::content with
>>    sub Apache ::Request::content { $CONTENT }
>Eew. :-)
>What happens if the request doesn't result in a 404?  Then
>you've slurped up the data destined for the resource..

Almost all of the POST request that occur on the websites we
maintain, are through a ModPerl handler.  If that handler just
uses user $r->content, there shouldn't be any problem.  To be
on the safe side, I should probably overload $r->read instead
of $r->content.  $r->content is basically a call to $r->read
anyway.

However, we still have some customers using "old fashioned"
CGI scripts.  They would indeed lose their POST data in this
scheme.  I'll probably hack this in such a way that it won't
slurp if it has "/cgi-bin" in the request.  Pretty sure that
solves my problem for now.


>...  I'm
>not sure whether the above would work, but it might be better
>than the first solution regardless of aesthetics.

Maybe a more generic approach to this, which wouldn't break any
existing ErrorDocuments, would be to add a flag to the ErrorDocument
directive that would cause the request body to _not_ be discarded,
thereby giving the option to the ErrorDocument handler to do with
it what wants:

ErrorDocument	404	/error404.lp	KeepRequestBody


Would that make sense?  Would it be possible to do, either in the
current 1.3 Apache development path or in the 2.0 path?  If it
makes sense and would not be impossible to do, I would look into
doing that myself.


Elizabeth Mattijsen
xxLINK Internet Services

[prev in list] [next in list] [prev in thread] [next in thread]