On 08/04/13 22:13, Carl Meyer wrote:
> Although the concept of a unified "request environ" that includes HTTP
> headers mashed together with various other environment and web server
> info may date back to CGI, it is not outdated; in fact it is a part of
> the WSGI specification too:
> http://www.python.org/dev/peps/pep-3333/#environ-variables
I realise it is part of the WSGI spec, but encoding the CGI
peculiarities into a more modern spec seems pretty misguided to me - you
have to create a WSGI-CGI gateway to run CGI programs anyway, and you
could put the backwards compatibility mapping there, instead of in the
WSGI spec. I actually wish that WSGI didn't do any HTTP parsing at all.
>> There is also the advantage of a *much* cleaner repr(request),
>> especially in a development environment, because you don't have all the
>> other junk from os.environ.
>
> If we are trying to make repr(request) really be a full reproduction of
> all relevant request data (such that the request instance could be fully
> reconstructed from it) then I don't think this goal is achievable; it is
> not an option (IMO) to remove WSGI environ data from the request
> entirely, because this would make data that is part of the WSGI spec
> inaccessible to Django users.
>
> (I haven't checked whether the current repr(request) meets the
> full-reconstruction criteria; if it already doesn't then I don't really
> care what we show in it, we could trim it down further with or without
> your proposed change.)
You can't currently reproduce the request this way - the stream for the
request body contents comes out as something opaque.
You're right we could trim the repr with or without my change - it would
simply have made the set of things to display more obvious.
We should probably consider the places where repr(request) is used. It's
probably just in logging systems. However, Sentry is one of the most
popular and it does it's own representation of the request object, it
seems, so if we left META alone it wouldn't be affected.
It seems to me that repr(request) is most useful for
development-environment debugging, and currently could be improved a lot
for that use case.
>> Is anyone strongly opposed to this? If not, in Aymeric's spirit of
>> decisiveness, I'll push it forward.
>
> I'm fine with new request.headers API; I'm opposed to deprecation of
> request.META.
I would be fine with your modification of my proposal, not least because
it would be a *lot* less work!
The only disadvantage is "two ways to do it". If you want to grep for a
particular header, you've got 2 things to grep for now. However, that
problem already existed due to META - you've got things like
QUERY_STRING and request.GET, HTTP_HOST and request.get_host(),
X_REQUESTED_WITH and request.is_ajax().
Regards,
Luke
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
