I like the new 'upload tempname' as well. That's better in a lot
of ways than 'upload save' which is just going to copy (rename?) the
temp file into another location when all you really want is to open up
the file wherever it is.
Damon
On Nov 14, 2008, at 11:19 AM, Massimo Manghi wrote:
Hi Karl,
as you are one of Rivet's masterminds it's good to hear from you
again.
Actually 'upload channel' works for me (apache2 and rivet code from
svn trunk)
but, as you said, 'upload data' complains about the server
configuration variable not
being set.
Karl Lehenbauer wrote:
This was tricky.
Apache has its own portable I/O library <http://apr.apache.org/docs/apr/1.2/group__apr__file__io.html
> that apparently is just a FILE * in Apache 1.3 but is an Apache-
defined C structure in 2.2. Rivet made some assumptions about it
that it shouldn't have, like that it could use the fileno() library
call to get the UNIX file descriptor.
I've got a fix working such that "upload channel" works with Apache
2 and "upload data" which has not been working in Apache 1.3 or 2.
I've also added a new subcommand, "upload tempname", to get the
name of the temporary file that contains the uploaded file for
those who want to roll their own.
In addition to working, it is now system independent without any
special code, like it'll work on NT and stuff.
The cost is that it opens the temp file that contains the uploaded
file, rather than grabbing the file handle out of the Apache
portable runtime file structure. There appears to be no "legal"
way to grab the file descriptor out of the apr_file_t structure, so
I think it's a small cost in overhead for something that's
intrinsically relatively high overhead anyway (uploading files),
and IMHO it's worth it to use the Apache file API in a standard
manner.
With your agreement I'd like to commit these changes.
no objection, I'm curious to see what difference caused one
subcommand to fail.
By the way, the "raw_post" command doesn't seem to work.
thank you for pointing this out. I never used this undocumented
command
but this could be an opportunity for doing it along with the fix.
By the way, I remember you came up with an idea about exploiting a
field
in 'request_rec' to pass custom data to the server for subsequent
logging.
IIRC you had already coded it, are you still willing to share it
with Rivet?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
