On Aug 7, 7:37 am, Rebecca K <rlskoe...@gmail.com> wrote:
> I'm working on an ARK (Archival Resource Key) resolver in django, and
> as part of the ARK spec I need to recognize and distinguish urls
> ending with '?' and '??' (no query string or anything else
> following).
>
> When I run my django app throughmod_wsgi, I have access to
> request.META['REQUEST_URI'], which contains the path plus the question
> mark. When I run my django app with manage.py runserver, I get a key
> error when I try to access REQUEST_URI. Same thing when I use the
> django test client.
>
> Anyone have any thoughts on how I can access the REQUEST_URI
> consistently no matter what environment the django app is running in?
>
> I'm not tied to using REQUEST_URI-- if there are other ways to detect
> the '?' on the end of the url, that serves my purpose just as well.
> But it seems that the all of the django HttpRequest object functions
> and properties have path and query string values that are too
> sanitized and don't give me access to this.
>
> Thanks in advance for any help or suggestions.
REQUEST_URI is not a value one should ever rely on for dispatch. This
is because it is entirely optional and will not be supplied by hosting
mechanisms. It is also the raw URL from the request and has not had
decoding of duplicate slashes removed, nor had any web server rewrite
rules applied. It therefore can be difficult to actually relate it to
the final SCRIPT_NAME and PATH_INFO unless you are going to duplicate
all the stuff that a specific web hosting mechanism may do to derive
SCRIPT_NAME and PATH_INFO from it.
Anyway, you shouldn't even need to access the REQUEST_URI unless
Django or the Django development server is doing something odd. For a
standard web server with WSGI support, you possibly should be able to
look at QUERY_STRING.
PATH_INFO: ''
QUERY_STRING: '?'
REQUEST_METHOD: 'GET'
REQUEST_URI: '/echo.wsgi??'
SCRIPT_NAME: '/echo.wsgi'
Well, at least to capture the case where the double question mark
occurs, as in that case the second question mark will be in
QUERY_STRING.
You can't through variables other than REQUEST_URI determine if there
was a question mark with an empty query string. Relying on that is
arguably going to be somewhat dodgy anyway.
In terms of what I was talking about with encoding and the problems it
can cause as far as blind matching without decoding, see examples
below.
PATH_INFO: ''
QUERY_STRING: '?'
REQUEST_METHOD: 'GET'
REQUEST_URI: '/%65cho.wsgi??'
SCRIPT_NAME: '/echo.wsgi'
PATH_INFO: '/e'
QUERY_STRING: '?'
REQUEST_METHOD: 'GET'
REQUEST_URI: '/echo.wsgi/%65??'
SCRIPT_NAME: '/echo.wsgi'
End result is that if some standard is based on a single question mark
and no actual query string content being different to no question mark
at all, they have been pretty stupid in doing that.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
