Lennart Regebro wrote:
I will check this into head this evening, and unless people scream tomorrow
I will check it into the 2.7 branch.

Please hold off. I've been meaning to revisit this for a while, and I have a bit of time to do so today and tomorrow. Also, virtual hosting is properly the domain of the request object, not the object being traversed. This is why the modified absolute_url() uses REQUEST.physicalPathToURL.

Yuppie wrote:
> 'relative to site object' is quoted from the API documentation of
> absolute_url()

The API documentation is incorrect, and the docstring in the method is correct:

     '''Return a canonical URL for this object based on its
        physical containment path, possibly modified by virtual hosting.
        If the optional 'relative' argument is true, only return the
        path portion of the URL.'''

"Relative" in this context refers to the concept of a "relative path" as used in rfc1808, not to a relationship with a Zope object. It is meant for use in situations such as redirection to a secure page from an insecure one (eg. 'https://example.com' + target.absolute_url(1)) where you would otherwise have to generate the complete URL and then break it apart.

Current behavior looks like this:

absolute_url( ): http://localhost:8180/temp_folder/test
absolute_url(1): temp_folder/test

absolute_url( ): http://www.example.com/temp_folder/test
absolute_url(1): temp_folder/test

absolute_url( ): http://www.example.com/test
absolute_url(1): test

absolute_url( ): http://www.example.com/foo/test
absolute_url(1): foo/test

This is entirely consistent, predictable, and easy to explain. The problem you are encountering is almost certainly due to a use of absolute_url where it shouldn't be used, or is used incorrectly.


Evan @ 4-am

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to