HttpResponse object should have 'content_type' argument (in additon to / instead of 'mimetype')

[Simon Willison]

I can never remember the 'mimetype' argument to HttpResponse; I always have to look it up. The corresponding HTTP header is 'Content-Type'; I think that content_type would be a more memorable and more accurate argument.

For example:

return HttpResponse(simplejson.dumps({
    'airports': airports
}), mimetype='application/json; charset=utf-8')

Should be:

return HttpResponse(simplejson.dumps({
    'airports': airports
}), content_type='application/json; charset=utf-8')

The charset=utf-8 bit further demonstrates that mimetype should be renamed - charset=utf-8 is a parameter, not part of the actual mime media type.

I suggest adding content_type as an alternative to mimetype; I see no particular need to deprecate mimetype and break existing code, although it may be something that should be removed in the future.

[Simon Willison]

Patch to add content_type argument without breaking mimetype

[Malcolm Tredinnick]

This looks reasonable. However, isn't the patch broken? If you pass in mimetype, but not content_type, then lines 162 and 163 will stomp all over line 161 in the new version. Looks like 163 should be "elif". Otherwise, looks like the right idea.

[Malcolm Tredinnick]

OK, I'm an idiot. The patch is not broken. Nothing to see here.

[Simon G. <dev@…>]

Want to write a few lines for the docs too?

[Malcolm Tredinnick]

The only change I made in the version I'm about to commit is to move the content_type parameter to the end of the constructor list to preserve backwards compatibility for people using positional arguments.

[Malcolm Tredinnick]

(In [5844]) Fixed #3526 -- Added content_type as an alias for mimetype to the HttpResponse constructor. It's a slightly more accurate name. Based on a patch from Simon Willison. Fully backwards compatible.