You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/10/28 05:33:49 UTC
[PATCH] proxy and ftp://site/dir//file
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);
Re: [PATCH] proxy and ftp://site/dir//file
Posted by Marc Slemko <ma...@worldgate.com>.
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,
> > <URL:ftp://myname@host.dom//etc/motd>, 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. <g>
> >
> > RFC959:
> >
> > CWD <SP> <pathname> <CRLF>
> > <pathname> ::= <string>
> > <string> ::= <char> | <char><string>
> >
> > 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);
> > > >
> > > >
> > >
> >
> >
>
Re: [PATCH] proxy and ftp://site/dir//file
Posted by Dean Gaudet <dg...@arctic.org>.
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.
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,
> <URL:ftp://myname@host.dom//etc/motd>, 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. <g>
>
> RFC959:
>
> CWD <SP> <pathname> <CRLF>
> <pathname> ::= <string>
> <string> ::= <char> | <char><string>
>
> 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);
> > >
> > >
> >
>
>
Re: [PATCH] proxy and ftp://site/dir//file
Posted by Marc Slemko <ma...@worldgate.com>.
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,
<URL:ftp://myname@host.dom//etc/motd>, 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. <g>
RFC959:
CWD <SP> <pathname> <CRLF>
<pathname> ::= <string>
<string> ::= <char> | <char><string>
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);
> >
> >
>
Re: [PATCH] proxy and ftp://site/dir//file
Posted by Dean Gaudet <dg...@arctic.org>.
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.
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);
>
>