[feature request] including HttpResponse(status=204) as an HttpResponse subclasses

181 views
Skip to first unread message

Philip Lee

unread,
Apr 5, 2017, 11:25:44 AM4/5/17
to Django developers (Contributions to Django itself)
Every Django view function MUST return an HttpResponse object, sometimes we just want to send data to the server and  don't want to send data back to the client , this probably lead Python users want to return None instead, however , this is not allowed in Django view function, I found  HttpResponse(status=204) may come for rescue in this case,  thus it would be better to include HttpResponse(status=204) as an HttpResponse subclasses for convenience so that could save Django users from asking those returning-null-response questions:
http://stackoverflow.com/questions/17557618/post-without-response-in-django-javascript-interaction
http://stackoverflow.com/questions/2131203/django-no-redirections
http://stackoverflow.com/questions/4123155/how-do-i-send-empty-response-in-django-without-templates

BTW, someone already implemented this feature  here, better to adopt it in Django 
http://django-extras.readthedocs.io/en/latest/ref/http-response.html

Tim Graham

unread,
Apr 5, 2017, 12:35:41 PM4/5/17
to Django developers (Contributions to Django itself)
Hi, this was already wontfixed here:
https://code.djangoproject.com/ticket/3362

with the rationale, "We've decided in the past not to add a new class for every single response code. You can already pass the status code in when creating the HttpResponse class, so that can be used in this case."

(found with this google search: httpresponse 204 site:code.djangoproject.com)

Philip Lee

unread,
Apr 6, 2017, 7:44:50 PM4/6/17
to Django developers (Contributions to Django itself)
I think you'd better write the decision in the document to stop Django users from making the same feature request in future !

Adam Johnson

unread,
Apr 7, 2017, 2:55:02 AM4/7/17
to django-d...@googlegroups.com
Personally I'd be in favour of adding such classes. It seems against the batteries-included philosophy that Django does not provide all of the standard codes as classes. I can never remember which codes correspond to which response types, if I saw status=204 in code it would be a 'magic number' for me and I'd have to look it up. HttpResponseRedirect and HttpResponsePermanentRedirect have been my friends in the past, I can imagine the same for HttpResponseNoContent. 

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2f619780-d6f1-4bce-8d34-40a18b87d798%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Adam

Brice PARENT

unread,
Apr 7, 2017, 3:37:29 AM4/7/17
to django-d...@googlegroups.com

Le 07/04/17 à 08:54, Adam Johnson a écrit :
Personally I'd be in favour of adding such classes. It seems against the batteries-included philosophy that Django does not provide all of the standard codes as classes. I can never remember which codes correspond to which response types, if I saw status=204 in code it would be a 'magic number' for me and I'd have to look it up. HttpResponseRedirect and HttpResponsePermanentRedirect have been my friends in the past, I can imagine the same for HttpResponseNoContent.

+1

And there are more than just HttpResponseRedirect and HttpResponsePermanentRedirect that are provided by now.

In django.http.response, you can find :

HttpResponseRedirect, HttpResponsePermanentRedirect, HttpResponseNotModified, HttpResponseBadRequest, HttpResponseNotFound, HttpResponseForbidden, HttpResponseNotAllowed, HttpResponseGone, HttpResponseServerError

of which 7 don't embed any code, just the status code (like what is asked for 204).

I'm not saying all of them are widely used enough to require an explicit class declaration (like status code 418) or even would mean anything in the context of a web framework, but the most common should, at least, be in the batteries. 204 is an example, but there probably are some others (like 426 and 505, when the world is switching to https).

-OR-

We should at least provide a reversed version of django.http.response.REASON_PHRASES (which doesn't exist anymore, I think), so that we could call :

HttpResponse(status=response_codes.no_content)

It makes it way less cryptic for both the writer and the readers of the code.

-Brice

Marc Tamlyn

unread,
Apr 7, 2017, 3:53:56 AM4/7/17
to django-d...@googlegroups.com
I would be happy to revisit that decision which was made 9 years ago. APIs returning unusual status codes such as 204 are much more common now than they were then. I can't think of a good reason not to add ~10-15 2-line classes.

Marc

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

Berker Peksağ

unread,
Apr 7, 2017, 6:19:00 AM4/7/17
to django-d...@googlegroups.com
On Fri, Apr 7, 2017 at 9:54 AM, Adam Johnson <m...@adamj.eu> wrote:
> Personally I'd be in favour of adding such classes. It seems against the
> batteries-included philosophy that Django does not provide all of the
> standard codes as classes. I can never remember which codes correspond to
> which response types, if I saw status=204 in code it would be a 'magic
> number' for me and I'd have to look it up. HttpResponseRedirect and
> HttpResponsePermanentRedirect have been my friends in the past, I can
> imagine the same for HttpResponseNoContent.

Alternatively, they can use the HTTPStatus enum from the stdlib if
they are on Python 3.5+:

from http import HTTPStatus

HttpResponse(status=HTTPStatus.NO_CONTENT)

--Berker

Adam Johnson

unread,
Aug 6, 2017, 4:17:22 PM8/6/17
to django-d...@googlegroups.com
I've made a ticket for this: https://code.djangoproject.com/ticket/28469

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

For more options, visit https://groups.google.com/d/optout.



--
Adam

Tim Graham

unread,
Aug 7, 2017, 11:42:55 AM8/7/17
to Django developers (Contributions to Django itself)
I think I prefer documenting Berker's suggestion rather than adding more classes to Django, unless perhaps, they add some additional functionality as HttpResponseNoContent does.

Did you intend to have response subclasses for all
57 values of http.HTTPStatus?


On Sunday, August 6, 2017 at 4:17:22 PM UTC-4, Adam Johnson wrote:
I've made a ticket for this: https://code.djangoproject.com/ticket/28469
On 7 April 2017 at 11:18, Berker Peksağ <berker...@gmail.com> wrote:
On Fri, Apr 7, 2017 at 9:54 AM, Adam Johnson <m...@adamj.eu> wrote:
> Personally I'd be in favour of adding such classes. It seems against the
> batteries-included philosophy that Django does not provide all of the
> standard codes as classes. I can never remember which codes correspond to
> which response types, if I saw status=204 in code it would be a 'magic
> number' for me and I'd have to look it up. HttpResponseRedirect and
> HttpResponsePermanentRedirect have been my friends in the past, I can
> imagine the same for HttpResponseNoContent.

Alternatively, they can use the HTTPStatus enum from the stdlib if
they are on Python 3.5+:

    from http import HTTPStatus

    HttpResponse(status=HTTPStatus.NO_CONTENT)

--Berker

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.



--
Adam

Adam Johnson

unread,
Aug 7, 2017, 4:11:25 PM8/7/17
to django-d...@googlegroups.com
Did you intend to have response subclasses for all 57 values of http.HTTPStatus?

I hadn't entirely thought it through before implementing :) I agree it's too much, and many are highly unlikely for Django applications to respond with, e.g. 203 Non-Authoritative Information.

I'll document the http.HTTPStatus solution and add only classes that provide extra functionality for Django-app-plausible status codes.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Adam
Reply all
Reply to author
Forward
0 new messages