Hi all,

This is already the subject of a ticket, but I didn't get a response
yet. Basically, the idea is replace things like:

  request.META['HTTP_ACCEPT']

with

  request.HEADERS['Accept']

request.META should be deprecated and replaced with request._META,
because it is just an implementation detail, and a really bizarre one at
that, full of cruft from a previous generation of web applications (CGI)
that should not be exposed in our API.

Anything else needed from META should also be replaced with a sensible API.

This might seem to be a big change simply for the sake of a clean API,
but I'm more and more motivated by these thoughts:

* Web development is hard enough as it is. "Explain this to a newbie
without getting embarrassed" is a good test.

* A general philosophy of pro-actively keeping things clean and sensible
is necessary to avoid being overrun with madness long term.

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.

The biggest problem is what to do with our test Client and
RequestFactory, which allow specifying headers as keyword arguments
using the CGI style of naming e.g.:

  self.client.get('/path', HTTP_X_REQUESTED_WITH='XMLHttpRequest')

Since keyword arguments can't have "-" in them, this is harder to
replace. We could either leave it as it is, or add a new 'headers'
keyword argument to these methods, deprecating **extra.

The silliness has infected other places, like SECURE_PROXY_SSL_HEADER
which follows the same CGI convention (and in each case the docs have to
note how to do it correctly!). In this case we can detect people using
the old style 'HTTP_' and raise a deprecation warning, and allow the
sensible way.

We would probably also need to add a few methods/attributes to
HttpRequest to proxy the few things you need from request.META that are
not headers, like REMOTE_ADDRESS and REMOTE_USER

Is anyone strongly opposed to this? If not, in Aymeric's spirit of
decisiveness, I'll push it forward.

https://code.djangoproject.com/ticket/20147

Regards,

Luke


-- 
Be careful of reading health books, you might die of a misprint.
      -- 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.


Reply via email to