David Allen <[EMAIL PROTECTED]> writes: > On Sat, Oct 19, 2002 at 07:12:27PM +0200, Oskar Sandberg wrote:
> > > Currently, the behavior of fred is to load the default document from a > > > mapfile when a nonexistant document name is requested. I.e. > > > SSK@Zk3lWHDM6VzA5k4nZWOq5xPl1rkPAgM/FreenetGallery/1//doesnt/exist.txt > > > returns the front page. > > > I've given this a shot in build 521, and the same behavior is present > through fproxy. Any idea what's going on? > Yes. The problem is that metadata processing is a bit more complicated than it looks. most URIs in freenet are DBR mapfiles; so when you fetch their key of SSK@blah/name//file.html, the node does: 1a) request SSK@blah/name 1b) parse the cdoc and try to match "file.html" with a document 1c) fail to match, act on the _default_ date-calculated redirect 2a) request SSK@blah/name-date 2b) parse the cdoc, match "file.html" with a document 2c) redirect to the actual uri: CHK@blah2 3a) request CHK@blah2 3b) notice the CHK has no metadata, so don't process anything The problem isn't that the default document is matched in step 1c, as that's necessary for proper functioning of DBRs; the problem is that if file.html wasn't in the cdoc at step 2b, when the final document was retrieved, "file.html" would still be sitting there waiting to be matched. (yes, this does mean one can have a URI like SSK@blah/name//section1//file.html) > As for what the correct response is, unless somebody wants to > introduce a new type of error, Data Not Found seems like the best to > me. After all, the data wasn't locateable. It's definately not an > incorrect URI or anything else like that. A case could be made for > "network error" I guess, but that's very non-specific and might it > prompt users to keep trying to get that key? > I disagree, I think it is a problem with the URI, and a InvalidURI response is very appropriate. > I'd really like to have this changed before 0.5 - I'll keep looking in > the source myself. Since this was earlier discussed and the metadata > spec changed, it would be nice for fred to adhere to its own metadata > spec for 0.5. :) > > -- > David Allen > http://opop.nols.com/ This detail of the metadata spec isn't really a big sticking point. If you want to muck about in the code and think you can produce a clean patch to fix things, look in GetRequestProcess.java in the getNextRequest method. That's where hobx was mucking about to fix this. 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
