#2782 closed defect (fixed)
mod_python's request.META["SERVER_PORT"] is always set to 0
Reported by: | anonymous | Owned by: | Adrian Holovaty |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have found small bug in core/handlers/modpython.py.
Namely, request.META["SERVER_PORT"]
under mod_python is always set to 0.
This is because it's set to self._req.server.port
in modpython.py, on line 88.
mod_python's docs say --
port Integer. TCP/IP port number. Same as CGI SERVER_PORT. This member appears to be 0 on Apache 2.0, look at req.connection.local_addr instead (Read-Only)
So I think it should be:
'SERVER_PORT': str(self._req.connection.local_addr[1]),
Because self._req.connection.local_addr[1]
is an integer, I think it should be string as other headers are.
Change History (13)
comment:1 by , 18 years ago
Description: | modified (diff) |
---|
comment:2 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [3866]) Fixed #2782 -- Fixed incorrect request.METASERVER_PORT for mod_python.
comment:3 by , 17 years ago
This bug is not fixed, or no longer fixed, in Django version=[0.97-pre-SVN-unknown]. I have applied the fix myself, and it works fine. Please, apply the fix to the SVN repository file again.
Django Version
$ python manage.py --version
0.97-pre-SVN-unknown
FILE: django/core/handlers/modpython.py
Change:
'SERVER_PORT': self._req.server.port,
TO...
'SERVER_PORT': str(self._req.connection.local_addr[1]),
comment:4 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This is not fixed in the 1.0 release.
comment:5 by , 16 years ago
The fix made in r3866 was reverted in r3927 because of the report it caused a crash in #2865. Now, that crash actually looks like a mod_python built with the wrong apr or something -- but to put this back in I think we need some evidence that it won't cause a crash with current levels of Apache/mod_python generally used on Macs. Anyone got a Mac to test on?
comment:6 by , 16 years ago
In #2865, most likely problem was that mod_python version used was compiled against a newer version of Apache/APR than what it was then loaded in to.
Even at that time, mod_python 3.2.8 was old as well and definitely not the latest version. Anyone still using mod_python 3.2.X should be shot as it has lots of bugs in it. Latest mod_python 3.3.1 has lots less bugs and not in areas where most would tread. ;-)
comment:7 by , 16 years ago
On Leopard (Mac OSX 10.5.5), mod_python 3.3.1 built for bundled-out-of-the-box Apache 2.2.8/Python 2.5.1,
I tested the following urls.py:
# coding: utf-8 """ This urls.py should yield following results: Pre-#2782 ( ModPythonRequest._req.server.port ): 0 Post-#2782 ( ModPythonRequest._req.connection.local_addr[1] ): 80 """ from django.conf.urls.defaults import * from django.http import HttpResponse from django.template import Template, Context urlpatterns = patterns('', (r'', lambda request: HttpResponse( Template("Pre-#2782 ( ModPythonRequest._req.server.port ): " \ "{{ pre2782 }}\n" \ "Post-#2782 ( ModPythonRequest._req.connection.local_addr[1] ): "\ "{{ post2782 }}") .render(Context(dict(pre2782=request._req.server.port, post2782=request._req.connection.local_addr[1]))), mimetype='text/plain')), )
The result yielded:
Pre-#2782 ( ModPythonRequest._req.server.port ): 0 Post-#2782 ( ModPythonRequest._req.connection.local_addr[1] ): 80
Seems to be working fine.
comment:8 by , 16 years ago
Interesting. The problem is not recreatable on the first box I tried (a Windows test box). It's running Apache/2.2.8 (Win32) mod_python/3.3.1 Python/2.5.2, and the current SVN code correctly sets the port number. Since the doc referenced mentions Apache 2.0, I figured it was fixed by Apache 2.2. However after you reported seeing port 0 returned on Apache 2.2.8, I tried it on my Linux box, running Apache/2.2.4 (Ubuntu) mod_python/3.3.1 Python/2.5.1 and sure enough it reports port 0 with the current code. So it seems more common than not (granted based on an unscientific 3-random-machine test) that the existing code doesn't work. In neither case I tried did the patch code cause any problem, so I'm inclined to put it back in.
comment:9 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
karen: the previous anonymous comment was ymasuda, who was the guy who reported #2685. He gave it a quick check with a current mod_python on his Mac. So whether you get to it first, or I do, doesn't matter. But I want to commit this. It's necessary for constructing the full URL.
comment:11 by , 16 years ago
Malcolm, OK, so I was going to re-commit the old fix, but I tested it first, with this little test view I had used earlier:
def portno(request): return HttpResponse("Port number in request is %d" % request.META["SERVER_PORT"])
This fails (TypeError) with the previously-applied fix because it casts to a str for consistency with the other headers. However until now this particular header has been an int, so I think it now needs to stay that way? Or because till now it has been mostly useless (except on this Windows machine I've got where the old code does report the real port number) are we OK changing the type? I'm tending to think not, and that we need to keep the same type it has been so far...but wondering if you have a different opinion?
(And I'd be interested in one of you magic crystal balls that reports who's who when posting anonymously...)
comment:12 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Fixed formatting of description.