IMO

In the Apache httpd 2.2 development, I've spent a lot of time on the proxy module, especially on the load balancer aspects of mod_proxy. This is an area which interests me and, based on the feedback and popularity of various presentations and webinars I've done, interests others as well. Not that long ago, on the httpd development list, we were discussing ways of enhancing the load balancing mechanism, with possibly a separate process/thread which periodically verifies the health of backend servers and maybe even providing information on their CPU load, stuff like that. With all that in mind, I started working on some additional load balancing (LB) implementations but ran into a snag. See, right before the proxy module runs the actual scheme handler (that is, "what to do with this request"), it calls a special hook: proxy_run_pre_request. The problem is that this hook is implemented as RUN_FIRST/DECLINED, meaning that all functions registered with this hook will run in order until one returns something other than DECLINED. Now this makes sense for a lot of hooks, but really thinking through the proxy module, it doesn't make sense for this one. Adding insult to injury, the one mod_proxy registers is also noted as APR_HOOK_FIRST, making this hook pretty much useless for other modules/submodules to be able to use if you want to also do "other things" at the same time. This is also the same for the proxy_run_post_request as well. So what I proposed was "fixing" these hooks instead be RUN_ALL, allowing other modules/submodules from using them (eg: OK, we've found a balancer, now do some checks against them, or create a timestamp or even bypass that selected balancer all together). Unfortunately, this can be considered an API change, which would make it unsuitable for inclusion in 2.2. In other words, this is easy to address/fix in trunk, but I also want to see this functionality in 2.2.x as well, and a major API change would forbid that. We haven't decided yet, conclusively, if, in fact, it is an API change, or, if it is, how "dangerous" it is (due to the way it's implemented, I'm pretty confident that no one is using it, but that doesn't carry too much weight). So what I'm looking at are adding 2 more hooks: proxy_hook_pre_shandler and proxy_hook_post_shandler, which runs before and after proxy_hook_scheme_handler (that's what the 'shandler' means). This would provide the hook opportunites that I think mod_proxy requires around this stage of processing, as well as being suitable for both trunk and 2.2. The disadvantage is that it adds some cycles to "work around" what is really (IMO), a design/API flaw. The overhead, from all my testing, is pretty much a non-issue, but it still seems an in-elegant solution. But it's likely the one I'll be pushing for...

I've used proftpd as my preferred FTP server for quite awhile now (although I do have a few sites running mod_ftp as well). I've also been baselining Transmit as my main OS X FTP client as well, supplementing the various CLI FTP clients as well. In any case, I've noticed that Transmit, after uploading files, tries to reset the timestamp on those files. The rub is that, except for the IETF draft, there really is no standard way to do this under FTP. There is overloading the MDTM FTP command, which some clients and servers support. There is also the SITE UTIME command as well. Unfortunately, there appears to be 2 popular formats for SITE UTIME:

SITE UTIME YYYYMMDDhhmm[ss] path

and

SITE UTIME path YYYYMMDDhhmm[ss] YYYYMMDDhhmm[ss] YYYYMMDDhhmm[ss] UTC

What is even more unfortunate is the proftpd doesn't support the MDTM overload and only supports the 1st flavor of SITE UTIME, whereas Transmit (and others) use the 2nd SITE UTIME flavor. So using the mod_site_misc.c proftpd contrib module as a starting point, I've crafted mod_site_utime.c. It's designed to just implement SITE UTIME (not other SITE commands, like mod_site_misc), and to add some extra flexibility on what is provided in mod_site_misc, like supporting timestamps with seconds values, supporting both format flavors and some basic error checking. I hear that later versions of proftpd will support the IETF drafts, but until that time, mod_site_utime just may be quite useful for a number of people.