[Dieter]
Looks as if your catalog were very old and still has entries with request relative resolution. ... With this information, you can try to analyse the problem in an interactive Python interpreter.
...
[Denis] To have either object or brain's path in output ("tagencies" list). The most interesting is that accessing via name I've got objects and paths [Dieter] this means that some paths could not be resolved (you get them as paths and cannot get objects). They probably form the "old" content still using request relative access. [Denis] but accessing via IP I've got ONLY object - no paths... [Dieter] In this case, all paths can be resolved into objects. You should select one or two failing paths and analyse them (this is done best in an interactive interpreter; under *nix, such an interpreter can be started with "bin/zopectl debug"). [Denis] Then I checked the paths I got for presence of objects on them. Objects are there, so I decided to use tagencies.append(portal.restrictedTraverse(path)) [Dieter] Try "unrestrictedTraverse" (will not work in untrusted code -- use the interactive interpreter). If "unrestrictedTraverse" can resolve the path, this means that the problem is a permission problem: the user is not allowed to access some object of "path". The catalog tries two ways to resolve a path: the modern one uses "physical path" related traversal, the old one uses request relative Url traversal. Due to a bug introduced in a recent Zope version (and I think fixed again in Zope 2.7.6), the modern approach performs too strict access controls. This may mean that the request relative Url traversal is used as a fallback. The request relative Url traversal is known to have severe problems with virtual hosting (also it is not yet known why host specification via name or IP should make a difference). I (at your place) would debug "brain.getObject()" for one of the failing brains. Please search the mailing list archives for some notes about debugging Plone/Zope. http://plonetarium.objectis.net -- Dieter