On Tuesday, October 21, 2003, at 04:05 PM, Fernando Martins wrote:
Ian Bicking wrote:
On Monday, October 20, 2003, at 02:37 PM, Fernando Martins wrote: [...]
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'm afraid I don't see the issue here. The way I see it, there is an (undocumented?) inconsistency between __str__ and __getattr__ (which gave me a bug). Does it make sense to have these virtual HTTP_* attributes? Why would someone rely on it? Also, if I make a typo in say HTTP_C00KIE, I'm getting a bug which could have been spotted imediately at the first run.
It probably is meant to cover up some browser-compatibility issues. Most browsers people use for testing act reasonably similar, but some HTTP/1.0 robots or old browsers will act funky and do dumb things -- but you'll never really notice it during testing. (OTOH, I wouldn't really care if these browsers and robots got exceptions, they're broken and very obsolete) I think it's okay that __str__ and __getattr__ aren't entirely consistent -- certainly in this case __str__ can't enumerate all possible HTTP_* headers. It would be more concerning if the documentation for HTTPRequest weren't consistent with its behavior. But I've yet to find good, thorough documentation for these basic objects, and nothing that is thorough enough that it covers this kind of behavior (though I guess I stopped looking for good Zope documentation of this sort a while ago -- maybe it exists and I just haven't seen it) -- so in the absence of documentation there's no such thing as Right and Wrong, just Is and Is Not (I'm not sure whether to wink or panic in response to that). -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org