David Allen <[EMAIL PROTECTED]> writes: > Is there something terribly obvious I'm missing or is this a bug? > > Running build 513, updated today, I tried something to see what would > happen. > > 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. > 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. > 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*? > > -- > David Allen 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 "". Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
