httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Edmundsson <>
Subject Re: mod_ftp, status and progress?
Date Mon, 26 Mar 2007 09:16:23 GMT
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 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.


>> * 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.

  Niklas Edmundsson, Admin @ {acc,hpc2n}      |
  It is always darkest before it goes totally black.

View raw message