Re: FTP OS-dependence, and new FTP RFC
On Sat, 4 Aug 2007, Micah Cowan wrote: Just a word of caution here: while RFC1738 tells this is the way to do it, there are servers and times where this approach doesn't work. (lib)curl has an option to specify the CWD style (multiple cwd, single cwd or no cwd) due to this... Could you be more specific about how it fails to work on some systems? I understand (from comments in wget) that OS/400 doesn't support hierarchies: but then no legitimate OS/400 FTP URL would include more than one dir component in its path. Sorry, but the exact details have escaped so I can't provide them right now. I'm sure someone will remind us later on if you change wget to multi-CWD ;-) I remember one situation has been that the server doesn't allow you to CWD into the dir, but allows you to CWD into the dir's subdir! So that "CWD dir1" fails, but "CWD dir1/dir2" works Given that probably most other user-agents follow the RFC in this regard Why do think that? I remember back when we made curl do this (April 2003), a guy named David Balazic posted an RFC1738 compliance summary where he tested a range of FTP clients and as I recall it very few of them used the multi-CWD way. Of course time has since passed so the situation may have changed, but I believe many still use the single CWD or even no CWD approach. Unfortunately that summary URL is now a 404... I'm having a little problem seeing how an FTP server that can't handle this could survive, particularly since, from the beginning of time, it's been the only way to reliably specify the directory path one wants. Reliably for multiple servers, no. But reliable for a specific server that you're using, sure. Technically, we can violate the RFCs (specifically, RFC 1738, which defines the ftp URL scheme in terms of a string of CWDs from the starting directory), if the FTP server starts us out in a directory other than / The particular login directory doesn't affect the CWD approach at all, since the URL gives the path relative to the login directory... Do you mean that wget tacks the path onto the value it gets from PWD, then? No I don't, I don't know how wget creates the dir it sends with CWD. In the quote above you wrote that "we can violate" ... "*if* the FTP server starts us out in a directory other than /" (my emphasis), and I just mentioned that you can do the exact same work no matter what the login directory is.
Re: FTP OS-dependence, and new FTP RFC
From: Hrvoje Niksic > I agree that string-of-CWDs would be better than the current solution. Well, that's good news. See, for example, the discussion around: http://www.mail-archive.com/wget@sunsite.dk/msg08233.html Also: http://www.mail-archive.com/wget@sunsite.dk/msg08447.html Steven M. Schweda [EMAIL PROTECTED] 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
--with-libssl-prefix and AC_LIB_HAVE_LINKFLAGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Someone recently reported an inability to specify the prefix for libssl. It seems the culprit is somehow the multiple invocation of the macro AC_LIB_HAVE_LINKFLAGS, even though they appear in exclusive conditional sections. If one removes the invocation of this macro from the gnutls-testing section, leaving the only invocation as the one in the openssl-testing section, openssl is detected normally. However, even if one replaces the invocation of AC_LIB_HAVE_LINKFLAGS() in the gnutls section with one identical to the way it is used in the openssl section, the one in the openssl section will fail. I'm not sure how this is happening, but part of the failure is that, in the generated "configure" shell script, $shextlib gets an empty value instead of "so", and the openssl test winds up looking for "/usr/local/lib/libssl." instead of "/usr/local/libssl.so", and of course fails to find it, so it doesn't get added to the library flags to the test-run of gcc for the libssl test program. I'm hoping that someone with a little more knowledge of our m4 macros and autoconf might be able to figure out what's going on with that. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtM0u7M8hyUobTrERCFdXAJ4v9SSexm0yu14YkTYtW9VLRnV+lwCfZjjE Bh3NhWfr/ANLD6ZyKbIvlP0= =I1Bs -END PGP SIGNATURE-
Re: FTP OS-dependence, and new FTP RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel Stenberg wrote: > On Fri, 3 Aug 2007, Micah Cowan wrote: > >> I have a question: why do we attempt to generate absolute paths and >> such and CWD to those, instead of just doing the portable >> string-of-CWDs to get where we need to be? > > Just a word of caution here: while RFC1738 tells this is the way to do > it, there are servers and times where this approach doesn't work. > (lib)curl has an option to specify the CWD style (multiple cwd, single > cwd or no cwd) due to this... Could you be more specific about how it fails to work on some systems? I understand (from comments in wget) that OS/400 doesn't support hierarchies: but then no legitimate OS/400 FTP URL would include more than one dir component in its path. Given that probably most other user-agents follow the RFC in this regard, I'm having a little problem seeing how an FTP server that can't handle this could survive, particularly since, from the beginning of time, it's been the only way to reliably specify the directory path one wants. >> Technically, we can violate the RFCs (specifically, RFC 1738, which >> defines the ftp URL scheme in terms of a string of CWDs from the >> starting directory), if the FTP server starts us out in a directory >> other than / > > The particular login directory doesn't affect the CWD approach at all, > since the URL gives the path relative to the login directory... Do you mean that wget tacks the path onto the value it gets from PWD, then? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtMn07M8hyUobTrERCPgQAJ9oFSrUYB88x+rvco/EbPEsgUr0/QCdF6WE Ih2fbwL4YAuSZAimHKrIGOI= =/fE7 -END PGP SIGNATURE-
Re: FTP OS-dependence, and new FTP RFC
Micah Cowan <[EMAIL PROTECTED]> writes: > I have a question: why do we attempt to generate absolute paths and > such and CWD to those, instead of just doing the portable > string-of-CWDs to get where we need to be? I think the original reason was that absolute paths allow crossing from any directory to any other directory without using "..". This is needed by the recursive download code, which downloads from multiple directories. I agree that string-of-CWDs would be better than the current solution.
Re: FTP OS-dependence, and new FTP RFC
On Fri, 3 Aug 2007, Micah Cowan wrote: I have a question: why do we attempt to generate absolute paths and such and CWD to those, instead of just doing the portable string-of-CWDs to get where we need to be? Just a word of caution here: while RFC1738 tells this is the way to do it, there are servers and times where this approach doesn't work. (lib)curl has an option to specify the CWD style (multiple cwd, single cwd or no cwd) due to this... Technically, we can violate the RFCs (specifically, RFC 1738, which defines the ftp URL scheme in terms of a string of CWDs from the starting directory), if the FTP server starts us out in a directory other than / The particular login directory doesn't affect the CWD approach at all, since the URL gives the path relative to the login directory...
FTP OS-dependence, and new FTP RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have a question: why do we attempt to generate absolute paths and such and CWD to those, instead of just doing the portable string-of-CWDs to get where we need to be? Technically, we can violate the RFCs (specifically, RFC 1738, which defines the ftp URL scheme in terms of a string of CWDs from the starting directory), if the FTP server starts us out in a directory other than /, and it makes OS portability easier. Obviously, interpreting the output of LIST will never be generally portable, but it seems like restricting our OS awareness to listings only can save us headaches later (and some code, to boot). It can also save us doing SYST and PWD at the beginning, if we don't have to interpret listings. Speaking of interpreting LIST output, a new FTP Extensions RFC 3659, has been added to update RFC 959, as of March of this year. It adds a couple new listing commands (MLST and MLSD) with well-defined output. It also defines officially a couple commands which are apparently common extensions, SIZE and MDTM, and modifies the definition of REST (also to bring FTP in line with common extensions). It also provides a way for servers to advertise that they use traditional Unix-like pathnames. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtBrl7M8hyUobTrERCP7gAJ9EOGKWL5Ho1hd8GgypK0Nwpr3+vgCcDNqN 51+WMpcHy56s+iq/ECBtJHk= =fAwz -END PGP SIGNATURE-
