Re: [freenet-support] Wget'ing freenet:USKs
Evan Daniel skrev: On Wed, Nov 18, 2009 at 9:17 PM, Dennis Nezic denn...@dennisn.dyndns.org wrote: 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:). 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:/u...@blah; or even http://127.0.0.1:/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. Yes, but that contradicts putting a slash /before/ the protocol identifier. ___ 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
Re: [freenet-support] Wget'ing freenet:USKs
On Thursday 19 November 2009 18:47:05 Andrew wrote: Evan Daniel wrote: Your browser has no clue how to handle a freenet: URL. Would it be possible to create a web browser plug-in to support freenet: URLs? If so, maybe the plug-in could control some things like no caching, no cookies, no maximum number of connections, etc. for freenet URLs? Also this might make it easier to simply block HTTP and HTTPS access entirely. Some of those things would be very difficult to control from a plugin. It makes sense eventually IMHO to have a dedicated browser for Freenet. signature.asc Description: This is a digitally signed message part. ___ 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
Re: [freenet-support] Wget'ing freenet:USKs
Evan Daniel wrote: Your browser has no clue how to handle a freenet: URL. Would it be possible to create a web browser plug-in to support freenet: URLs? If so, maybe the plug-in could control some things like no caching, no cookies, no maximum number of connections, etc. for freenet URLs? Also this might make it easier to simply block HTTP and HTTPS access entirely. -- Andrew. ___ 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
Re: [freenet-support] Wget'ing freenet:USKs
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:). 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:/u...@blah; or even http://127.0.0.1:/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
Re: [freenet-support] Wget'ing freenet:USKs
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. 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
