Another way that people can screw up SCRIPT_NAME determination in a
server is not to use WSGIScriptAlias, but use WSGIScriptAliasMatch and
not use it properly.
So, please post the actual Apache configuration snippet you are using
to map you Django application with mod_wsgi so can verify that the
c
On Jan 4, 12:45 pm, davathar wrote:
> Here's more information I've been able to find. Evidently there's a
> problem in some configurations wheremod_wsgieither isn't receiving
> or isn't passing SCRIPT_NAME.
>
> When I use this test script in the wsgi file I get an empty string as
> the value fo
Here's more information I've been able to find. Evidently there's a
problem in some configurations where mod_wsgi either isn't receiving
or isn't passing SCRIPT_NAME.
When I use this test script in the wsgi file I get an empty string as
the value for SCRIPT_NAME. And from what I gather that's wh
On Sun, Jan 3, 2010 at 5:15 PM, davathar wrote:
> Ramiro, thanks for the links. That other thread does seem to describe
> the same problem and results in it being identified as a bug in the
> core urlresolvers. Unfortunately the work around of "RewriteRule ^/
> studio$ /studio/ [R] " doesn't wo
Ramiro, thanks for the links. That other thread does seem to describe
the same problem and results in it being identified as a bug in the
core urlresolvers. Unfortunately the work around of "RewriteRule ^/
studio$ /studio/ [R] " doesn't work for me for some reason. Maybe I'm
misapplying it.
Eit
On Sun, Jan 3, 2010 at 4:44 PM, davathar wrote:
> Thank you for the responses so far. But I still haven't identified
> the solution to this seemingly simple issue.
>
> The behavior also happens when I use the URL tag in a template like
> this "{% url case_url case.id %}" the result I get is "/su
Thank you for the responses so far. But I still haven't identified
the solution to this seemingly simple issue.
The behavior also happens when I use the URL tag in a template like
this "{% url case_url case.id %}" the result I get is "/support/case/
1/ ".
So the inconsistency is that when I mak
Bill: Tried that, but it made no difference. case is resolving ok.
The problem is with the first part "/helpdesk/" dropping off when
doing a reverse. The same behavior happens when I use the URL tag in
a template. "{% url case_url case.id %}" I get /support/case/1/
without the /helpdesk in fr
Since your urlconf is passing "case" as a named (keyword) argument, you
(may) have to pass it that way to reverse:
...reverse('case_url', kwargs={'case':case.id})...
Bill
On Mon, Dec 28, 2009 at 8:22 PM, davathar wrote:
> I'm stuck on a "reverse" problem. The 'case' view is supposed to
> re
I'm using mod_wsgi. which contains this to point to settings:
os.environ['DJANGO_SETTINGS_MODULE'] = 'helpdesk.settings'
application = WSGIHandler()
My settings.py has:
#
ROOT_URLCONF = 'helpdesk.urls'
#
INSTALLED_APPS = (
#
'helpdesk.support',
#
)
If I manually key in example.com/helpdesk/s
Are you running it through a mod-python handler? From your urls.py, it
looks like it would handle ^support as the first level match and then
continue for "/case", so the reverse URL seems to be correct, i.e. /
support/case/1.
How are you tacking the "/helpdesk" to your request initially?
On Dec
I'm stuck on a "reverse" problem. The 'case' view is supposed to
record posted info, then reload the same page. But it's dropping the
first part of the URL on the redirect and I've not been able to figure
out why.
It should be going to .com/helpdesk/support/case/1/ But it's going
to .com/suppor
12 matches
Mail list logo
