Code

Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#2782 closed defect (fixed)

mod_python's request.META["SERVER_PORT"] is always set to 0

Reported by: anonymous Owned by: adrian
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: UI/UX:

Description (last modified by adrian)

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.

Attachments (0)

Change History (13)

comment:1 Changed 8 years ago by adrian

  • Description modified (diff)

Fixed formatting of description.

comment:2 Changed 8 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:3 Changed 6 years ago by adroffner@…

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 Changed 5 years ago by walter.stafford@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

This is not fixed in the 1.0 release.

comment:5 Changed 5 years ago by kmtracey

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 Changed 5 years ago by grahamd

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 Changed 5 years ago by anonymous

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 Changed 5 years ago by kmtracey

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 Changed 5 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to 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:10 Changed 5 years ago by mtredinnick

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

comment:11 Changed 5 years ago by kmtracey

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 Changed 5 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

(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 Changed 5 years ago by mtredinnick

(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().

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.