On Wed, Nov 18, 2009 at 9:17 PM, Dennis Nezic <denn...@dennisn.dyndns.org> wrote: > On Sun, 15 Nov 2009 10:44:07 -0500, Evan Daniel wrote: >> On Sun, Nov 15, 2009 at 7:36 AM, Dennis Nezic >> <denn...@dennisn.dyndns.org> wrote: >> > What is the purpose of the "freenet:" notation? (Besides >> > complicating things.) >> > >> > When I try to "wget -r -np" a freesite, most links will not be >> > fetched >> > -- namely those that still use the ubiquitous "/USK..." url. >> > (Because -np, --no-parent, is meant to only fetch files within a >> > particular directory and not ascend to other parent directories, >> > thus preventing the fetching of the entire Internet.) So >> > because /USK.. and /freenet:USK.. are effectively two different >> > parent folders, simply using "-np" won't work. >> > >> > Instead of "-np" I have to explicitly list the key in both >> > notations as parameters to "--include-directories" .. resulting in >> > a hideous command line. (Which includes the USK key 3 times.) >> > >> > I wouldn't mind doing this if there was SOME reason for it? (Was it >> > meant to be used as a protocol identifier, like http: mailto:, etc?) >> > But is it really necessary to "301 Permanently Move" queries to the >> > freenet:* links? >> >> It is in fact a protocol identifier, like http:, mailto:, irc:, etc. >> The idea is that the proper URL of a Freenet file is something like >> "freenet:u...@crypto/sitename/edition/filename". The FProxy web >> interface provides, for convenience, a way to translate freenet: URLs >> into http: ones. >> >> Eventually, it would be nice to support this in other ways. For >> example, FProxy should rewrite freenet: URLs into the appropriate >> http: equivalent. Alternately, a browser plugin that knew how to >> handle freenet: URLs (ie, translate them into http: and then handle >> normally), and prevented downloading of content from any other URL >> type would improve security and require less content filtering (thus >> making it easier to support more complex file types). See bug 3414: >> https://bugs.freenetproject.org/view.php?id=3414 >> >> Would it help if the content filter rewrote all "/u...@..." URLs into >> "/freenet:u...@..."? That would probably be a fairly easy change. >> (The content filter already does URL rewriting, to insert the checked >> http pages for example.) If so, please file a bug report. > > Hrrm. I'm no expert, but doesn't the "/freenet:u...@..." URL syntax seem > wrong? The protocol should be the first thing, not in the pathname? And > it would only make sense if it was from some external non-fproxy > source, no? I mean, if the user is already accessing fproxy, what's the > point of freenet: references? > > It seems to me that having fproxy automatically redirect > all /USK@ /CHK@ /SSK@ links to /freenet:USK@ links is pointless in the > first place ... and getting rid of this redirection should solve the > problem and simplify things too :).
No, the / at the beginning is perfectly correct. Your browser has no clue how to handle a freenet: URL. The / at the front means it should use that as an absolute path to construct an http: URL from, using the current server (typically 127.0.0.1:8888). FProxy provides a translation layer that gets the corresponding freenet: URL over http in that format. The proper URL of a Freenet document is not "u...@blah" or "http://127.0.0.1:8888/u...@blah"; or even "http://127.0.0.1:8888/freenet:u...@blah";. It's "freenet:u...@blah". The http version is simply a translation that your browser (and wget, etc) knows what to do with. URLs are supposed to begin with a protocol: identifier. Including only a portion of the correct URL in the translation layer, while not exactly wrong, seems silly. The proper solution is to make sure that all http: URLs for Freenet documents follow the same format. As long as that format is consistent, I don't think there's any problem with wget and such. Evan Daniel _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
