Changes between Version 126 and Version 127 of BackwardsIncompatibleChanges

Timestamp:

Sep 14, 2007, 4:52:08 PM (17 years ago)

Author:

Jacob

Comment:

Added notice about HttpResponse.headers

BackwardsIncompatibleChanges

@@ -38 +38 @@
  * [6075] Sept. 9, 2007: [http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#django-admin.pyandmanage.pynowrequiresubcommandstoprecedeoptions django-admin.py and manage.py now require subcommands to precede options]
  * [6177] Sept. 14, 2007: [http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#django.views.i18n.set_languagerequiresaPOSTrequest django.views.i18n.set-language requires a POST request]
+ * [6212] Sept. 14, 2006: [http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#django.http.HttpResponsenowhascase-insensitiveheaders HttpResponse now has case-insensitive headers, and response.headers is no longer directly accessible]
 
 == Database constraint names changed ==
@@ -380 +381 @@
 
 Code calling this view must ensure that a POST request is now made, instead of a GET. This means you can no longer use a link to access the view, but must use a form submission of some kind (e.g. a button).
+
+== django.http.!HttpResponse now has case-insensitive headers ==
+
+In a number of changes starting with [6212], {{{HttpResponse}}} headers were made case-insensitive. 
+
+As a side-effect, could break code that accesses {{{response.headers}}} directly, and specifically broke the idiom {{{if header in response.headers:}}}. 
+
+So {{{response.headers}}} has been renamed to {{{response._headers}}}, and {{{HttpResponse}}} now supports containment checking directly. You should now use {{{if header in response}}} instead of {{{if header in response.headers}}}.