Re: is Apache::Request upload->fh lazy or not?
Joe Schaefer <[EMAIL PROTECTED]> writes: > Apache::Request would be a nice feature. Recently David Prosa added ^^^ Ugh- he's David *Welton*, and he's using libapreq in his mod_dtcl module. Damn, that's twice I've done that to him - I'm very, very sorry, David :( -- Joe Schaefer
Re: is Apache::Request upload->fh lazy or not?
"Thomas K. Burkholder" <[EMAIL PROTECTED]> writes:
> Hi again,
>
> Thanks to those who helped me with the install issue. I've mostly
> resolved that, and now have a new question that seems much more
> mod-perl-ish:
>
> I have code that does essentially this:
>
> sub handler {
> my $r = shift;
> $r = Apache::Request->new($r);
> my $handle = $r->upload('filename');
> my $fh = $handle->fh;
> ...
> }
>
> I'd like to write upload code that shows progress (via a fork and
> refresh header trick - don't worry about that). What I'm wondering is,
> by the time I get $fh above (or even by the time I'm in the handler for
> all I know) do I already have the entire file uploaded, or is it done
> lazily as reads are performed on $fh? I'm not very good at reading this
> XS stuff, but I looked at libapreq and from that I suspect it's all done
> up front. Is there any way to read it incrementally?
>
> Has anyone solved this problem before? I want to provide an upload
> function for my web app that shows the user periodic progress or maybe
> even allows them to cancel it part way through. Is this too much of a
> reach for http/mod_perl?
I've managed to do this in the past by modifying mod_proxy on the
front-end server, but I think the ability to do this from within
Apache::Request would be a nice feature. Recently David Prosa added
an upload hook to the C API for libapreq, and yesterday I put together
a patch to Request.xs that provides a Perl interface.
It would work something like this:
my $hook = sub {
my ($upload, $buf, $len, $data) = @_;
my $fh = $upload->fh;
print $fh $buf;
warn "HOOK_DATA = $data: wrote $len bytes for " . $upload->name;
}
my $apr = Apache::Request->new( Apache->request,
HOOK_DATA => "Some parameters",
UPLOAD_HOOK => $hook,
);
my $parm_table = $apr->param; # causes upload parsing to begin
my $upload = $apr->upload('file');
my $fh = $upload->fh;
...
In this case, &$hook will be called in place of the normal internal
(buffered) writes to a temp file. Note that $upload->fh now
must auto-vivify a temp file if none was created by libapreq itself.
That's probably a feature, but it may require some care if the hook sub
is poorly designed. $upload->size will now count the size of the data
sent by the browser, which may or may not be the same as the size of
the temp file (depending on what the hook does with it). Otherwise
upload objects should behave normally ($upload->fh still dup's and
seek's outside of the hook sub).
I'll post the diff to the apreq-dev list after I've tested it a bit
more. Also, please contact me or follow up to the list if anyone has
some comments/suggestions for improving the API before committing it to
CVS.
Thanks.
--
Joe Schaefer
Re: is Apache::Request upload->fh lazy or not?
At 05:17 AM 4/14/01, Thomas K. Burkholder wrote: >I'd like to write upload code that shows progress (via a fork and >refresh header trick - don't worry about that). What I'm wondering >is, >by the time I get $fh above (or even by the time I'm in the handler >for >all I know) do I already have the entire file uploaded, or is it done >lazily as reads are performed on $fh? I'm not very good at reading >this >XS stuff, but I looked at libapreq and from that I suspect it's all >done >up front. Is there any way to read it incrementally? > >Has anyone solved this problem before? I want to provide an upload >function for my web app that shows the user periodic progress or maybe >even allows them to cancel it part way through. Is this too much of a >reach for http/mod_perl? I thought that using your mod_perl process to handle file uploads was a Bad Thing. You might want to think about using a domain cookie, and pass the client off to a lighter process to handle the upload, rather than having a giant mod_perl apache process spinning for five minutes while someone uploads a file. Just my $0.02. cheers, Todd
Re: is Apache::Request upload->fh lazy or not?
* Thomas K. Burkholder ([EMAIL PROTECTED]) [010414 04:28]: > ... > > I'd like to write upload code that shows progress (via a fork and > refresh header trick - don't worry about that). What I'm wondering is, > by the time I get $fh above (or even by the time I'm in the handler for > all I know) do I already have the entire file uploaded, or is it done > lazily as reads are performed on $fh? I'm not very good at reading this > XS stuff, but I looked at libapreq and from that I suspect it's all done > up front. Is there any way to read it incrementally? > > Has anyone solved this problem before? I want to provide an upload > function for my web app that shows the user periodic progress or maybe > even allows them to cancel it part way through. Is this too much of a > reach for http/mod_perl? AFAIK, the server doesn't even start processing the request until the entire file is uploaded. In the past (when it's absolutely necessary) I've popped up a tiny Javascript window telling the user to be patient (or whatever) while the file uploads. The returned page has an onload() handler which closes the window. It's not a progress bar, but it's something that hopefully prevents the user from getting impatient, clicking the browser's 'Stop' button and resubmitting the request. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
is Apache::Request upload->fh lazy or not?
Hi again,
Thanks to those who helped me with the install issue. I've mostly
resolved that, and now have a new question that seems much more
mod-perl-ish:
I have code that does essentially this:
sub handler {
my $r = shift;
$r = Apache::Request->new($r);
my $handle = $r->upload('filename');
my $fh = $handle->fh;
...
}
I'd like to write upload code that shows progress (via a fork and
refresh header trick - don't worry about that). What I'm wondering is,
by the time I get $fh above (or even by the time I'm in the handler for
all I know) do I already have the entire file uploaded, or is it done
lazily as reads are performed on $fh? I'm not very good at reading this
XS stuff, but I looked at libapreq and from that I suspect it's all done
up front. Is there any way to read it incrementally?
Has anyone solved this problem before? I want to provide an upload
function for my web app that shows the user periodic progress or maybe
even allows them to cancel it part way through. Is this too much of a
reach for http/mod_perl?
Thanks in advance,
//Thomas
Thomas K. Burkholder
[EMAIL PROTECTED]
Re: Apache::Request::upload
The template contains the ENCTYPE="multipart/form-data",
uses METHOD="POST", and the action is my handler.
I initialize the object with:
my $r = 'Apache'->request();
my $apr = 'Apache::Request'->new($r);
From within my local CGI class I get the Apache::Request class reference
from
the passed hash ref and set up the meta-data:
$self->{_ApacheRequest} = $args->{ApacheRequest};
This line always returns undef (but it works with the example program):
$self->{_ApacheRequestUpload} = $self->{_ApacheRequest}->upload;
I have also tried in the init object:
my $upload = $apr->upload;
Thank you,
Dave
Tobias Hoellrich wrote:
> At 10:04 AM 7/14/00 -0600, Dave Thomas wrote:
> >Hello,
> >
> >Question: Why does the Apache::Request object not return an Upload
> >object when
> >there was a file sent.
> >
> > Backgroud: I have pulled the sample script from the Apache::Request
> >distribution and
> >used that in my handler, this instance works fine. When I try to use it
> >incorporated
> >with the object model developed here it closes up shop and goes home.
> >
> > I initialize the Apache::Request object in an init function from the
> >handler. This is then
> >used to display the templated html content with
> >$apr->send_http_header('text/html');
> >at its top. I've made certain that the Request object's address remains
> >the same
> >throughout this process. When I fill in the file field and submit the
> >first thing that the
> >script does after initializing the Request object is try to initialize
> >the Upload object, this
> >fails miserably with a return value of undef.
> >
>
> Most likely you're missing a
>
> ENCTYPE="multipart/form-data"
>
> in your FORM tag.
>
> Hope this helps
> Tobias
Re: Apache::Request::upload
At 10:04 AM 7/14/00 -0600, Dave Thomas wrote:
>Hello,
>
>Question: Why does the Apache::Request object not return an Upload
>object when
>there was a file sent.
>
> Backgroud: I have pulled the sample script from the Apache::Request
>distribution and
>used that in my handler, this instance works fine. When I try to use it
>incorporated
>with the object model developed here it closes up shop and goes home.
>
> I initialize the Apache::Request object in an init function from the
>handler. This is then
>used to display the templated html content with
>$apr->send_http_header('text/html');
>at its top. I've made certain that the Request object's address remains
>the same
>throughout this process. When I fill in the file field and submit the
>first thing that the
>script does after initializing the Request object is try to initialize
>the Upload object, this
>fails miserably with a return value of undef.
>
Most likely you're missing a
ENCTYPE="multipart/form-data"
in your FORM tag.
Hope this helps
Tobias
Apache::Request::upload
Hello,
Question: Why does the Apache::Request object not return an Upload
object when
there was a file sent.
Backgroud: I have pulled the sample script from the Apache::Request
distribution and
used that in my handler, this instance works fine. When I try to use it
incorporated
with the object model developed here it closes up shop and goes home.
I initialize the Apache::Request object in an init function from the
handler. This is then
used to display the templated html content with
$apr->send_http_header('text/html');
at its top. I've made certain that the Request object's address remains
the same
throughout this process. When I fill in the file field and submit the
first thing that the
script does after initializing the Request object is try to initialize
the Upload object, this
fails miserably with a return value of undef.
Any suggestions on how to proceed would be greatly appreciated.
Kind regards,
Dave Thomas
[EMAIL PROTECTED]
