[Zope] Problem with alternate path and request

[Fernando Martins]

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.

BTW, which method is implicitly called to generate the HTML representation
of the objects (like in "structure request")?

Cheers,
Fernando