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
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
""; or even
"";.  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
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to