You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2007/12/06 21:26:41 UTC

svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Author: wrowe
Date: Thu Dec  6 12:26:40 2007
New Revision: 601843

URL: http://svn.apache.org/viewvc?rev=601843&view=rev
Log:
Come closer to a release by backing-up the version from Covalent-numbering
series to an ASF numbering series, and prepare for the first GA release
to be numbered 1.0.0.

This means 0.9.0 is an obvious numbering schema for alpha/beta's.


Modified:
    httpd/mod_ftp/trunk/STATUS
    httpd/mod_ftp/trunk/include/mod_ftp.h

Modified: httpd/mod_ftp/trunk/STATUS
URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/STATUS?rev=601843&r1=601842&r2=601843&view=diff
==============================================================================
--- httpd/mod_ftp/trunk/STATUS (original)
+++ httpd/mod_ftp/trunk/STATUS Thu Dec  6 12:26:40 2007
@@ -9,41 +9,49 @@
 
   * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
   * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
-  * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
 
 Release history:
     [NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
           while x.{even}.z versions are Stable/GA releases.]
 
-    3.0.0   : in development
-    2.x.x   : prior to entry into incubation
+    0.9.0   : in development
 
 Contributors looking for a mission:
 
-    * Just do an egrep on "TODO" or "XXX" in the source.
+  * Just do an egrep on "TODO" or "XXX" in the source.
 
-    * Review the bug database at: http://issues.apache.org/bugzilla/
+  * Review the bug database at: http://issues.apache.org/bugzilla/
 
-    * Review the "PatchAvailable" bugs in the bug database:
+  * Review the "PatchAvailable" bugs in the bug database:
 
-      https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
+    https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&component=mod_ftp&keywords=PatchAvailable
 
-      After testing, you can append a comment saying "Reviewed and tested".
+    After testing, you can append a comment saying "Reviewed and tested".
 
-    * Open bugs in the bug database.
+  * Open bugs in the bug database.
 
 
 RELEASE SHOWSTOPPERS:
 
-    * Port source code to 2.3 + event MPM compatibility.
+  * HELP results are trashed by ABOR OOB data handling hackery.  Must
+    eliminate these from the list of registered commands and handle
+    them properly in the OOB data channel read.  Pity that the client
+    developers never bothered to learn the telnet protocol.
+
+  * FTPLimit* family of directives share an FTPLimitDBFile across hosts,
+    yet fail to scope their tracking records to the corresponding host.
+    
+REALLY NICE TO WRAP THESE UP:
 
-    * Implement EPSV and EPRT for IPv6 compatibility.
-      (PASV is now substantially IPv6 compatible, but doesn't have the
-      representation mechansim to provide true IPv6 interoperability.)
+  * Implement AUTH GSSAPI/ADAT commands from RFC2228 Appendix I.
 
-CURRENT RELEASE NOTES:
+  * Process named virtual hosts based on USER foo@hostname syntax
+    (stripping @hostname prior to user-auth processing).
 
+CURRENT RELEASE NOTES:
 
+  * EPSV and EPRT need real world testing for different routing and DMZ
+    cases and validating a range of IPv6-enabled clients' interop.
 
 CURRENT VOTES:
 
@@ -51,9 +59,15 @@
 
 REFERENCES:
 
-    * "FILE TRANSFER PROTOCOL (FTP)", Postel, Reynolds
-      http://www.rfc.net/rfc959.html
+  * "FILE TRANSFER PROTOCOL (FTP)", Postel, Reynolds
+    http://www.ietf.org/rfc/rfc959.txt
+
+  * "FTP Security Extensions", Horowitz, Lunt
+    http://www.ietf.org/rfc/rfc2228.txt
+
+  * "FTP Extensions for IPv6 and NATs", Allman, Ostermann, Metz
+    http://www.ietf.org/rfc/rfc2428.txt
 
-    * "Securing FTP with TLS", Ford-Hutchinson
-      http://www.rfc.net/rfc4217.html
+  * "Securing FTP with TLS", Ford-Hutchinson
+    http://www.ietf.org/rfc/rfc4217.txt
 

Modified: httpd/mod_ftp/trunk/include/mod_ftp.h
URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/include/mod_ftp.h?rev=601843&r1=601842&r2=601843&view=diff
==============================================================================
--- httpd/mod_ftp/trunk/include/mod_ftp.h (original)
+++ httpd/mod_ftp/trunk/include/mod_ftp.h Thu Dec  6 12:26:40 2007
@@ -23,7 +23,7 @@
 #ifndef MOD_FTP_H
 #define MOD_FTP_H
 
-#define MODFTP_VERSION "3.0.0-dev"
+#define MODFTP_VERSION "0.9.0-dev"
 
 /* FTP header has a couple of defines... on win32
    rather than including it, we'll just hack em in



Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Guenter Knauf <fu...@apache.org>.
Hi Bill,
>> Just a hint: last time I tested also with cURL which caused for whatever
>> reason a segfault with mod_ftp (r525888); so if possible you should also
>> try some transfers with cURL...

> Hmmm - any chance you were using IPv6?
nope - IPv4.
> The patches I committed
> today resulted from chasing down a segfault this week, where we
> didn't discover the sa of the local address, and it simply blew up.
> Now we fail over to a generic adapter, and ultimately fail cleanly
> if that doesn't succeed.
the problem with r525888 was that there were cases when r->user was NULL which then segfsaulted in strcmp() or another str* function... - NetWare cant deal with that....

Guen.



Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> 
> Just a hint: last time I tested also with cURL which caused for whatever reason a segfault with mod_ftp (r525888); so if possible you should also try some transfers with cURL...

Hmmm - any chance you were using IPv6?  The patches I committed
today resulted from chasing down a segfault this week, where we
didn't discover the sa of the local address, and it simply blew up.
Now we fail over to a generic adapter, and ultimately fail cleanly
if that doesn't succeed.

Bill

Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Guenter Knauf <fu...@apache.org>.
Hi Bill,
>> then there's another issue with mod_ftp.c which I will soon look at....

> Please let me know, if you say alls' well, I'll tag.
well, as you've seen I've committed a simple fix (no var declarations after function calls), and now all compiles fine for NetWare; then loaded with my old config from this spring when I last was on mod_ftp (yeah, sorry, so much other things....), and it still loaded fine; did some limited testing with FileZilla, and could transfer files anonymously (up/down); nothing more tested yet.
Also did a compile on a SuSE Linux box, and worked too with old config and anonymous...
So from my limited testing I would say go ahead and T&R a beta, and lets see what others find out.

Just a hint: last time I tested also with cURL which caused for whatever reason a segfault with mod_ftp (r525888); so if possible you should also try some transfers with cURL...

Guen.



Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Hi,
>> Who's interested in seeing a T&R and helping make the release happen?
> me.

Cool.  I've backed out the extra "ABOR" aliasing from trunk so we can tag
a beta, and if someone cares they can add compensation for all of the
weirder OOB behaviors that we see in the 'real world'.  I've also documented
the oddness of looking across hosts within the LimitDBFile, so nobody
should be surprised.

They are marked showstoppers, but that's not a showstopper to beta IMHO.

> then there's another issue with mod_ftp.c which I will soon look at....

Please let me know, if you say alls' well, I'll tag.

Bill

Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Hi,
>> here's what makes it compile - however first hunk seems not nice...
> just commited slightly modified patch.

Much prettier, thanks :)

Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> here's what makes it compile - however first hunk seems not nice...
just commited slightly modified patch.

Guenter.



Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> Who's interested in seeing a T&R and helping make the release happen?
me. But current code doesnt compile for Ipv4 due to improper ifdefs in ftp_commands.c;
here's what makes it compile - however first hunk seems not nice...

--- ftp_commands.c.orig	Fri Dec 07 19:38:14 2007
+++ ftp_commands.c	Fri Dec 07 19:47:40 2007
@@ -1515,11 +1515,13 @@
             addr = c->local_ip;
             family = APR_INET;
         }
-#endif
         else {
+#endif
             addr = c->local_ip;
             family = c->local_addr->family;
+#if APR_HAVE_IPV6
         }
+#endif
     }
     else if (arg[0] == '1' && !arg[1]) {
         if (c->local_addr->family == AF_INET
@@ -1760,9 +1762,9 @@
     /* XXX: Anything special to handle IPv6 ip_addr string where c->remote_ip
      * is IPv4 mapped?
      */
-    if (((c->local_addr->family == APR_INET) && (family == APR_INET)) ||
+    if (((c->local_addr->family == APR_INET) && (family == APR_INET))
 #if APR_HAVE_IPV6
-            ((c->local_addr->family == APR_INET6) && (family == APR_INET6))
+            || ((c->local_addr->family == APR_INET6) && (family == APR_INET6))
 #endif
        ) {
         apr_sockaddr_info_get(&sa, c->local_ip, family,


then there's another issue with mod_ftp.c which I will soon look at....

Guenter.



Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 6, 2007, at 3:40 PM, William A. Rowe, Jr. wrote:

>> URL: http://svn.apache.org/viewvc?rev=601843&view=rev
>> Log:
>> Come closer to a release by backing-up the version from Covalent- 
>> numbering
>> series to an ASF numbering series, and prepare for the first GA  
>> release
>> to be numbered 1.0.0.
> >
> > This means 0.9.0 is an obvious numbering schema for alpha/beta's.
>
> I'd like to propose to T&R the very first ASF-beta (or -alpha if  
> troubles
> are discovered) very shortly, as soon as the questions below are  
> resolved.
>
> First question, are there testers who will test/vote on the module?
> Second question, are there any real showstoppers to a beta?  My  
> thoughts...
>
>>  RELEASE SHOWSTOPPERS:
>>  +  * HELP results are trashed by ABOR OOB data handling hackery.   
>> Must
>> +    eliminate these from the list of registered commands and handle
>> +    them properly in the OOB data channel read.  Pity that the  
>> client
>> +    developers never bothered to learn the telnet protocol.
>
> This is a real problem since it may confuse clients and is generally
> badness.  I'd hold the tag for a solution to this.
>
>> +  * FTPLimit* family of directives share an FTPLimitDBFile across  
>> hosts,
>> +    yet fail to scope their tracking records to the corresponding  
>> host.
>
> If there's no fix, I'd just mark those directives as experimental  
> and call
> it baked.
>
> Who's interested in seeing a T&R and helping make the release happen?
>

Count me in (as we talked about @ AC :) )


Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 6 Dec 2007, William A. Rowe, Jr. wrote:

> First question, are there testers who will test/vote on the module?

I'm game for testing. Our environment is strictly anonftp read-only 
though, so I won't test the non-anon stuff. Having the thing work with 
mod_cache would be absolute bliss, but I guess that's an item to chew 
on after the first release ;)

>> +  * FTPLimit* family of directives share an FTPLimitDBFile across hosts,
>> +    yet fail to scope their tracking records to the corresponding host.
>
> If there's no fix, I'd just mark those directives as experimental and call
> it baked.

If it's documented how it works, that's fine. Although, if they don't 
scope correctly per-host they should probably be server-wide to avoid 
confusion by people that doesn't read the fine print.

> Who's interested in seeing a T&R and helping make the release happen?

I'm keen on helping out.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  If you call your doctor Bones, YMBAT
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: svn commit: r601843 - in /httpd/mod_ftp/trunk: STATUS include/mod_ftp.h

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> URL: http://svn.apache.org/viewvc?rev=601843&view=rev
> Log:
> Come closer to a release by backing-up the version from Covalent-numbering
> series to an ASF numbering series, and prepare for the first GA release
> to be numbered 1.0.0.
 >
 > This means 0.9.0 is an obvious numbering schema for alpha/beta's.

I'd like to propose to T&R the very first ASF-beta (or -alpha if troubles
are discovered) very shortly, as soon as the questions below are resolved.

First question, are there testers who will test/vote on the module?
Second question, are there any real showstoppers to a beta?  My thoughts...

>  RELEASE SHOWSTOPPERS:
>  
> +  * HELP results are trashed by ABOR OOB data handling hackery.  Must
> +    eliminate these from the list of registered commands and handle
> +    them properly in the OOB data channel read.  Pity that the client
> +    developers never bothered to learn the telnet protocol.

This is a real problem since it may confuse clients and is generally
badness.  I'd hold the tag for a solution to this.

> +  * FTPLimit* family of directives share an FTPLimitDBFile across hosts,
> +    yet fail to scope their tracking records to the corresponding host.

If there's no fix, I'd just mark those directives as experimental and call
it baked.

Who's interested in seeing a T&R and helping make the release happen?

Bill