Opened 18 years ago

Closed 15 years ago

Last modified 15 years ago

#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 Adrian Holovaty)

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 Adrian Holovaty, 18 years ago

Description: modified (diff)

Fixed formatting of description.

comment:2 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: newclosed

(In [3866]) Fixed #2782 -- Fixed incorrect request.METASERVER_PORT for mod_python.

comment:3 by adroffner@…, 16 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 walter.stafford@…, 16 years ago

Resolution: fixed
Status: closedreopened

This is not fixed in the 1.0 release.

comment:5 by Karen Tracey, 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 Graham Dumpleton, 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 anonymous, 15 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 Karen Tracey, 15 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 Malcolm Tredinnick, 15 years ago

Triage Stage: UnreviewedAccepted

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:10 by Malcolm Tredinnick, 15 years ago

Err ... #2865, not #2685, but you get the idea.

comment:11 by Karen Tracey, 15 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 Malcolm Tredinnick, 15 years ago

Resolution: fixed
Status: reopenedclosed

(In [9512]) Fixed #2782 -- Make the server port available through the modpython handler.
(Originally applied in r3866, reverted in r3927 and now verified as correct).

comment:13 by Malcolm Tredinnick, 15 years ago

(In [9513]) [1.0.X] Fixed #2782 -- Make the server port available through the modpython
handler. (Originally applied in r3866, reverted in r3927 and now verified as
correct).

Backport of r9512 from trunk. This is a bugfix, since the value is used in
HttpRequest.get_host().

Note: See TracTickets for help on using tickets.
Back to Top