On Fri, 23 Mar 2007, William A. Rowe, Jr. wrote:
* Play well with mod_cache, if a file has been requested with HTTP a
FTP request should reuse the cached copy. Last time I checked
mod_ftp only did subrequests which mod_cache didn't act on.
In terms of using 'top level' requests in lieu of subrequests, it's
not low hanging fruit but definitely worth the refactoring. Doing this
against httpd trunk/ will show up the API's that httpd is missing for
providers of resource-based servers such as ftp.
OK. This will need more investigation then, the easiest solution
would seem to be to get the subrequest interaction with mod_cache
right. Bright insights are welcome.
* Both passive and active mode MUST work. I think there was some
issues causing it to always use 0.0.0.0 in passive mode last time I
checked.
fixed afaik, unless you are on win2000 and didn't DisableWin32AcceptEx
in 2.2.4 release (apr 1.2.8). The fix is in trunk and will percolate
out as apr 1.2.9 (or later) with 2.2.5.
Nice.
* Large file support MUST work (we serve DVD images). Last time I
checked there was a whole slew of LFS issues with the mod_ftp
globbing code which was simply broken since it didn't use the information
gathered by configure and didn't use APR - it should be ripped out
and replaced with APR stuff instead IMHO. It makes no sense to keep
that mess just o keep httpd 2.0 compatibility...
Patches welcome, yes this needs some refactoring.
Any thoughts on how to do this? My mind tend to be focused on "what
needs to work for anonftp" in this regard, and that means naively
listing a directory without any thoughts on file permissions and such.
If a file/directory is within the anonftp tree it's OK to include it
in the listing.
However, if there's some special care that needs to be done when
supporting file uploads (only listing directories which the auth:ed
user have access to and other special stuff) I will probably miss this
unless someone clued does the high level design.
* IPv6 MUST work. I think this is being addressed.
I'd fixed the traditional interfaces (PORT/PASV) but we need to hack
together EPRT/EPSV support, yet.
OK. This shouldn't be too hard, given that EPRT/EPSV doesn't differ
too much from PORT/PASV.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
It is always darkest before it goes totally black.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
