On Wed, Oct 09, 2002 at 09:22:35PM -0500, Edgar Friendly wrote: > David Allen <[EMAIL PROTECTED]> writes: > > Fetch this key: > > SSK@rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/FF//cant/possibly/exist/dammit > > > > Why does this pull up the front page of Freenet Forever? > > > The metadata spec doesn't specify behavior for a name that's not > listed in the control document. > > > Rinse, lather, and repeat for arbitrary keys under > > SSK@rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/FF// that don't exist, and you get > > the same result. > > > It's perfectly valid to return the default entry in a cdoc when a > unknown name is requested.
Well I guess that depends on how you look at it. I always thought that the mapfile was something of a hashtable, with names as keys and CHK's as values. If you look at it like that, it makes no sense that the default entry would be returned. Of course I guess there are other ways of looking at it. > > This happens through the servlet, but it also happens when using raw > > FCP connections, so it's not just that the servlet is trying to do the > > right thing and backing up to the default file when it can't find the > > key that's requested. > > > Raw FCP connections do *not* do any metadata processing at all, so > this can't be a true statement. I misspoke - I was referring to fetching things through FCP connections using tools like fcpget rather than the servlet. These tools can process redirects. > > The way I read this, fred should check for an entry named > > "cant/possibly/exist/dammit" in the mapfile. Is it standard behavior > > for it to redirect to the default file when it can't find an entry for > > a key, and if so, *why*? > > If it's what most clients do, then it's standard. There's no real > need to give an error result when requesting an unknown name, and the > easiest thing to do is use the default field to determine the action. > > If you want to make a case why I should put my foot down and spec it > one way or the other, go ahead. The only sorta-special case that's > needed is for the default name to match "". Here's my brief case. It really violates the principle of least suprise for a name that doesn't exist to map to the default file. Whether or not it's right, some people think of freenet keys sort of like URIs or pathnames. You definately can't do this type of thing with URIs or pathnames. You also can't do it with any freenet key that doesn't require a mapfile lookup somewhere. (I.e. KSK@foo/bar/hello is not the same thing as KSK@foo/bar/) So why should mapfiles introduce a strange exception to the way keys are put together? If the metaphor for freenet is something of an abstracted filesystem, I think it's pretty clear why this is weird behavior. Also I wonder about strange consequences for users. This effectively means that even if a link on a freesite is horribly broken, it might pull up the front page of the freesite which would probably be weird to say the least for the user. I can see somebody making a case for the fact that this would be good for users since it provides them with data they wouldn't have otherwise gotten (they would have gotten a DNF) but again it's pretty counterintuitive, and as a user, I'd probably wonder where the hell I was if I clicked on a bad link to Freenet Forever's help section and ended up looking at the front page. It's also misleading. As a hypothetical, let's say you wrote a program to run a dictionary attack against a freesite. (Yes that would be dumb since you could just fetch the mapfile and know what's out there, but for the sake of argument...) So you fetch SSK@pubkey/site//word then SSK@pubkey/site//otherword and so on. Every single request you make will succeed. Bizarre. Or look at it the other way - can anybody think of a good reason why it should be the way it currently is? How does this suprise the user less than returning a DNF or error would when a nonexistent key is requested? What value does this provide? -- David Allen http://opop.nols.com/ ---------------------------------------- She suddenly decides that he was it's time to drop some unexplained and badly placed pronouns we. -- Book I _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
