On Monday, October 20, 2003, at 02:37 PM, Fernando Martins wrote:
Ian Bicking wrote:
On Sunday, October 19, 2003, at 06:00 PM, Fernando Martins wrote:
<p tal:content="request/HTTP_X_FORWARDED_FOR | request/REMOTE_ADDR"></p>
doesn't work as expected: HTTP_X_FORWARDED_FOR returns an empty string rather than failling in favor of REMOTE_ADDR.
This means that something defined "HTTP_X_FORWARDED_FOR" even when you did not use virtualisation.
You know, that you can view the request with '<p tal:content="structure request">'?
Yes, and I think it's a bug because it doesn't appear in the request.
If you want to confirm this, you should try to use container.REQUEST.HTTP_X_FORWARDED_FOR from a Python script, or maybe just tal:content="python: repr(request.HTTP_X_FORWARDED_FOR)" -- even though the request doesn't list that variable among its headers, it may still return a value for that attribute. The only way to test if an attribute exists is to attempt to get the attribute. Perhaps (I don't know) the request object returns "" for any HTTP_* attribute that is not found.
Ok, tried it and got no error, just an empty string.
So, it is either a bug on the request object which contains the attribute HTTP_X_FORWARDED_FOR when it shouldn't (i.e., when the request went from the client straight to Zope). But maybe it should always have it.
Or it is a bug in the "structure request" which doesn't display the attribute even if it is there.
I assume it was a design choice, and changing it would break backward compatibility. I'd recommend just using tal:content="python: request.HTTP_X_FORWARDED_FOR or request.REMOTE_ADDR".
BTW, which method is implicitly called to generate the HTML representation of the objects (like in "structure request")?
__str__ should be it. You'll want to pay attention to __getattr__ as well, as HTTPRequest's __getattr__ probably is what returns an empty string for HTTP_* variables that aren't found. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org