Changes between Version 126 and Version 127 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
09/14/07 16:52:08 (8 years ago)
Author:
jacob
Comment:

Added notice about HttpResponse.headers

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v126 v127  
    3838 * [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]
    3939 * [6177] Sept. 14, 2007: [http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#django.views.i18n.set_languagerequiresaPOSTrequest django.views.i18n.set-language requires a POST request]
     40 * [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]
    4041
    4142== Database constraint names changed ==
     
    380381
    381382Code 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).
     383
     384== django.http.!HttpResponse now has case-insensitive headers ==
     385
     386In a number of changes starting with [6212], {{{HttpResponse}}} headers were made case-insensitive.
     387
     388As a side-effect, could break code that accesses {{{response.headers}}} directly, and specifically broke the idiom {{{if header in response.headers:}}}.
     389
     390So {{{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}}}.
Back to Top