Under the wrong circumstances, reap can die with this error message (or similar?):
Can't locate object method "host" via package "URI::_foreign" at /usr/local/lib/site_perl/URI/WithBase.pm line 48.
In my experience with LWP, the most common cause for this is assuming that all URI objects will universally support the host() method. This is not the case with relative URIs, some non-standard URIs, or even some standard URIs which by definition do not have hostnames. I've not seen "URI::_foreign" cited in error messages of this nature before, but to me it implies a URI that is either non-standard or of a standard form not yet recognized by LWP.
So far, the pages I've encountered that cause this error all have something in common. They all have only a single A tag (and a closing /A tag), but no HREF attribute to go with it--just left caret, A, right caret. So far I haven't been successful in reproducing the bug by creating a test HTML file with such an empty A tag.
Hmmm, the line identified in the error message is the AUTOLOAD method of URI::WithBase. Maybe this isn't reap's fault after all?
I made a mistake earlier. The problem does not appear to be caused by empty A tags. It appears to be caused by A tags with HREFs using non-standard URLs. The real culprit was a page with a link to a "javascript:" URL. I'm using muffin, which was getting rid of that URL before I had a chance to view the HTML in Netscape.
I think I have successfully traced the bug to Harvest::Controller::URLFilter::HostLimit::check().
Interesting thing: If I tried to test the object methods (e.g. "$obj->url->can('host')"), the "Rejected:" messages mentioned in bug #125403 changed from "Rejected: RobotsTxt" to "Rejected: HostLimit" and crawling ground to a halt. (There was also a weird error about an incomplete SOIF object.)
So instead I used an eval block to catch the otherwise fatal error. Now things seem to work fine, and "javascript:" URLs are rejected by the HostLimit filter. And bug #125403 is back to the way it was. :-)
I will post my patch for this to the Patch Manager.
The "weird error about an incomplete SOIF object" is actually a complaint from Metadata::SOIF about "@DOCUMENT" objects, which it doesn't seem to understand. I have seen it happen under other circumstances. Perhaps this should be reported as a separate bug?