On Mon, Apr 8, 2013 at 9:02 PM, Luke Plant <l.plant...@cantab.net> wrote:
> 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.
request.META is not just headers. What happens to the things that are
arbitrarily decided to be "not needed"? Who decides that HTTP_HOST is
important, but SERVER_PROTOCOL is not?
>
> 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 basis of web development was CGI. From CGI came everything.
Therefore, almost all webservers - Apache, nginx - almost all
frameworks - RoR, PHP, Django - that deal with the web will have
similar or equivalent environment hashes like this.
The convention for headers (uppercase header name, s/-/_/g, prepend
'HTTP_') is similarly ubiquitous.
Your argument is that this structure is confusing to the absolute
newbie who has never programmed a web application in his life. My
counter argument is that changing it would be confusing to anyone who
has ever programmed a web application in the last 20 years.
>
> 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.
This seems a problem with the API to Client and RequestFactory, not a
problem with request.META
>
> 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.
Again, to me that seems like the flaw is in the code handling
SECURE_PROXY_SSL_HEADER. Yes, that code does need to look up the
header name in request.META, it does not need to be specified in that
format.
>
> 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.
Changing this just in Django seems wrong - in fact it says that the
only thing of relevance in request.META is headers.
One man's cruft is another man's dinner. Everything in request.META is
of interest to someone, somewhere. When I'm debugging a failed
request, anything in request.META may be of interest.
If the intention is to make header handling easier for beginners to
understand, it might make more sense to normalize how one accesses and
sets headers in django at the same time. Having code like this:
response.HEADERS['Wibble'] = request.HEADERS['Wibble']
makes more sense than:
response['Wibble'] = request.HEADERS['Wibble']
I'd be -1 against dropping request.META, -1 on changing anything in
repr(request), +1 on adding re(quest|sponse).HEADERS that reads from
META/writes to _headers.
Cheers
Tom
--
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.
