"ZPublisher.BaseRequest.BaseRequest.traverse" expects "has_key"

[Dieter Maurer]

The following code in "ZPublisher.BaseRequest.BaseRequest.traverse" is buggy:

        # Note - no_acquire_flag is necessary to support
        # things like DAV. We have to make sure
        # that the target object is not acquired
        # if the request_method is other than GET
        # or POST. Otherwise, you could never use
        # PUT to add a new object named 'test' if
        # an object 'test' existed above it in the
        # heirarchy -- you'd always get the
        # existing object :(
        if (no_acquire_flag and
            hasattr(parents[1], 'aq_base') and
            not hasattr(parents[1],'__bobo_traverse__')):
            if not (hasattr(parents[1].aq_base, entry_name) or
                    parents[1].aq_base.has_key(entry_name)):
                raise AttributeError, entry_name

Apparently, it tries to verify that "entry_name" was not acquired. Unfortunately, it expects "parents[1]" to implement a
"has_key" and that is rarely the case. Moreover: meanwhile "entry_name" can also be located with Zope3 means
and not only with attribute access (taken care of by the "hasattr") and subscription access (failed trial to handle
this with the "has_key").
Thus, the code above needs a significant overhaul.

[Andreas Jung (ajung)]

Something for you, Lennard?

[Dieter Maurer (d.maurer)]

In addition, the implementation of HEAD seems to be broken when "Five" views are involved.

The primary failure is at the code above. But, when this code is removed, the "HEAD" would be implemented
identically to "GET" which contradicts HTTP/1.1 (it prohibits the inclusion of a response entity in a "HEAD" reponse).

[Lennart Regebro (regebro-gmail)]

I could probably do something with this, yes. We could probably use traversal instead of this lookup to solve this, I think.

Dieter, do you have a test case or a use case?

[Dieter Maurer (d.maurer)]

We are receiving HEAD requests for a Five view -- which fail in the code above as "PARENTS[1]" (a CMFCore.PortalObject")
does not implement "has_key". Even if it had "has_key", the code above would break as the view is neither an attribute
nor an item of "PARENTS[1]" (but located via Zope 3 traversal).

In our particular case, the HEAD requests come from a broken application. But HEAD is also frequently used by search engines (for index verification) and the code above could then lead to massive error rates due to failing HEAD requests.

[Hanno Schlichting (hannosch)]

The has_key is still present in todays SVN trunk.

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.