Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 10083 invoked by uid 6000); 28 Oct 1997 05:52:05 -0000 Received: (qmail 10032 invoked from network); 28 Oct 1997 05:52:00 -0000 Received: from valis.worldgate.com (marcs@198.161.84.2) by taz.hyperreal.org with SMTP; 28 Oct 1997 05:52:00 -0000 Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) with SMTP id WAA10021 for ; Mon, 27 Oct 1997 22:51:58 -0700 (MST) Date: Mon, 27 Oct 1997 22:51:57 -0700 (MST) From: Marc Slemko To: TLOSAP Subject: Re: [PATCH] proxy and ftp://site/dir//file In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Mon, 27 Oct 1997, Dean Gaudet wrote: > It would appear Navigator does not follow these rules. For example, I > just watched it issue "CWD /pub/" for ftp://ftp.arctic.org/pub/. I think > it also special cases stuff like "ftp://ftp.arctic.org/./foo" -- that will > eliminate the leading / on the CWD. But isn't it arguable that those are relative URLs which must be resolved into absolute ones by the client? For: ftp://ftp.freebsd.org/pub//FreeBSD/ Navigator 3 does: SIZE /pub//FreeBSD/ 550 /pub//FreeBSD/: not a plain file. CWD /pub//FreeBSD/ 250 CWD command successful. ...which doesn't fit in with _anything_, but it is understandable why they want to eliminate the huge latency of doing a seperate CWD for each component. Sigh. Whatever we do we violate a spec. I guess I would give the FTP one less weight, but... I'm not sure the URL one completely makes sense. > > Dean > > > On Mon, 27 Oct 1997, Marc Slemko wrote: > > > On Mon, 27 Oct 1997, Dean Gaudet wrote: > > > > > What does squid do in this case? 'cause I'm not sure this is a valid > > > change ... like what about obscure silly systems like, oh, vms... maybe a > > > null CWD does something. > > > > While that may be true, I don't think it is reasonable to expect > > ftp://site/dir//file to generate one. While it may not be defined to work > > properly, I have never even thought of hearing of anything that said it > > should generate a "CWD ". Damn. 1738 does say: > > > > On the other hand, > > , would "CWD " with a null > > argument, then "CWD etc", and then "RETR motd". > > > > But... we can't send that since sending "CWD " isn't a valid ftp > > command so pttth. > > > > RFC959: > > > > CWD > > ::= > > ::= | > > > > But then again, "CWD" does have a well-defined meaning, ie. cd ~ even if > > it isn't in the spec. But that is different from "CWD ". > > > > I don't see how 1738 can override 959, OTOH 959 is only half a spec > > anyway and few could live in the world just following it. Sigh. > > > > I would check: > > > > Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. > > > > but it is so ancient it is dead. > > > > Anything updating 959 that I missed? > > > > > > > > Dean > > > > > > On Mon, 27 Oct 1997, Marc Slemko wrote: > > > > > > > Trying to get a URL like ftp://site/dir//file through mod_proxy fails > > > > because Apache tries a "CWD " for the empty path component. Regardless of > > > > if the given URL can be considered valid, I think the below change to > > > > avoid this behavior is appropriate. > > > > > > > > Index: modules/proxy/proxy_ftp.c > > > > =================================================================== > > > > RCS file: /export/home/cvs/apachen/src/modules/proxy/proxy_ftp.c,v > > > > retrieving revision 1.40 > > > > diff -u -r1.40 proxy_ftp.c > > > > --- proxy_ftp.c 1997/09/30 21:02:14 1.40 > > > > +++ proxy_ftp.c 1997/10/28 04:20:40 > > > > @@ -626,6 +629,10 @@ > > > > *strp = '\0'; > > > > > > > > len = decodeenc(path); > > > > + if (len == 0) { > > > > + path = strp + 1; > > > > + continue; > > > > + } > > > > bputs("CWD ", f); > > > > bwrite(f, path, len); > > > > bputs("\015\012", f); > > > > > > > > > > > > > > > >