After setting encoding in view, request.REQUEST is not deleted

[Xia Kai(夏恺)]

Steps to repeat this bug

>>> str = "msg=%28%D0%A1%C3%B7%C9%B3%29"     # GBK encoded URL.
>>> from django.core.handlers.wsgi import WSGIRequest
>>> fakeenv = {'QUERY_STRING': str, 'REQUEST_METHOD': 'GET'}
>>> request = WSGIRequest(fakeenv)
>>> request.encoding        # This would return nothing, meaning no encoding is set yet.
>>> request.GET['msg']    
u'(\u0421\xf7\u0273)'
>>> request.REQUEST['msg']
u'(\u0421\xf7\u0273)'       # This is not correctly decoded, which is accepted, because no encoding is given.
>>> request.encoding = "GBK"# Set encoding
>>> request.GET['msg']  
u'(\u5c0f\u6885\u6c99)'     # GET is deleted and regenerated, so it's decoded correctly.
>>> request.REQUEST['msg']
u'(\u0421\xf7\u0273)'       # This is not acceptable, for we have provided the correct encoding.

Affected Code

The problem is, in the definition of HTTPRequest class, a _set_encoding method is provided, which would delete GET and POST after view function have provided encoding information. When the view function ask for GET and POST again, they would be re-generated. However, both modpython and wsgi request class added a shortcut dictionary named REQUEST, which is not deleted upon encoding change.

IMHO, design decision would be required as to whether to add request.REQUEST into the base HTTPRequest class and modify the _set_encoding function, or to override default _set_encoding method in both modpython and wsgi request class.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Tim Graham]

request.REQUEST is deprecated and will be removed in Django 1.9, so I think we can "won't fix" this.