Custom HTTP status reason phrases are not supported

[Gustavo Narea]

At present, Django hard-codes the HTTP status reason phrases based on an integer that represents the HTTP status code, forcing the recommended phrases by the HTTP specification.

Note they are just the recommended/default phrases and developers should be allowed to override these phrases. For example, I may want to return the following and Django should allow me to do so:

403 Get out

Or,

200 Everything is fine

See: ​http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1

In order to support this, Django could have the following code in django.http:HttpResponse.__init__:

        if isinstance(status, basestring):
            # The status is given as a real HTTP status header, so we should
            # tell the code and the reason apart for Django:
            (status_code, status_reason) = status.split(" ", 1)
            status_code = int(status_code)
            self.status_reason = status_reason or None
        else:
            # The status has been given the old way supported by Django, simply
            # the status code as an integer:
            status_code = status
            self.status_reason = None

And the following on django.core.handlers.wsgi:WSGIHandler.__call__():

        if response.status_reason:
            status_text = "%s %s" % (response.status_code, response.status_reason)
        else:
            try:
                status_text = STATUS_CODE_TEXT[response.status_code]
            except KeyError:
                status_text = 'UNKNOWN STATUS CODE'

If any Django user wants to use this functionality before it gets implemented, they may use twod.wsgi: ​http://bitbucket.org/2degrees/twod.wsgi/

[gisle]

Test that the custom response shows up on the WSGI level as well

[James Bennett]

1.2 is feature-frozen, moving this feature request off the milestone.

[Gustavo Narea]

Replying to ubernostrum:

1.2 is feature-frozen, moving this feature request off the milestone.

This can hardly be a feature. It's a fix for partially broken HTTP support.

[Russell Keith-Magee]

@Gustavo:

Is there any condition under which the existing implementation will raise an error or cause data loss in the absence of a custom status message?

Is there any standard that is violated by not allowing a custom status message?

The answer to both of these questions is No. Therefore, this isn't a bug fix. It's a feature request.

It may be an extremely useful new feature, but that doesn't change the fact that it is still a feature, and Django 1.2 is feature frozen.

[patchhammer]

0002-Test-that-the-custom-response-shows-up-on-the-WSGI-l.patch fails to apply cleanly on to trunk

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Claude Paroz]

Updated patch, tuple instead of string

[Claude Paroz]

Just attached an updated patch. I choose to pass a tuple as the status argument, instead of a string that has to be parsed, which is always fragile.

[Aymeric Augustin]

I couldn't care less about this feature request, but the approach shown in the patch looks all right.

I don't have an opinion on using a string or a tuple or a new keyword argument to pass the status text.

The patch is out of date; otherwise, in the interest of crossing one ticket off the list, this is RFC.

[Aymeric Augustin]

Actually, since this isn't a particularly useful feature, and I don't expect anyone to ever need it, it'd be nice if it didn't have any overhead.

[Gustavo Narea]

Hi, aaugustin.

Replying to aaugustin:

Actually, since this isn't a particularly useful feature, and I don't expect anyone to ever need it, it'd be nice if it didn't have any overhead.

What do you mean by "overhead"? I think a new keyword argument would be cleaner, but I'm happy to update update the patch in either direction. Which is the approach you prefer?

Thanks.

[Paul McNett <p@…>]

This is hackish, quickly written, and tested for only 10 minutes or so but I implemented custom status codes by monkeypatching the django.core.handlers.wsgi.STATUS_CODE_TEXT dict like:

import django.core.handlers.wsgi as wsgi

class NextDict(dict):
    def __init__(self, *args, **kwargs):
        self._nextdict = {}
        super(NextDict, self).__init__(*args, **kwargs)

    def set_next(self, key, value):
        """
        The next time this key is queried, return the passed value.
        After that, use the default.
        """
        self._nextdict[key] = value

    def __getitem__(self, key):
        if key in self._nextdict:
            v = self._nextdict[key]
            del(self._nextdict[key])
            return v
        return super(NextDict, self).__getitem__(key)

wsgi.STATUS_CODE_TEXT = NextDict(wsgi.STATUS_CODE_TEXT)

And then when I want my response to have a custom message for it's status code:

    class MyView(request):
        wsgi.STATUS_CODE_TEXT.set_next(200, "hello")
        return HttpResponse("hello again")

I googled for similar ideas and didn't find anyone doing this, so I thought it may give someone some ideas to develop this into a plugin or something. It wouldn't add overhead to the default (and reasonable) implementation, but would help some of us satisfy our requirements easily and without adding too much extra overhead...

[Aymeric Augustin]

#20328 is a duplicate.

[Anler Hp]

For the API of my company we use this feature in a lot of places.
One of the use cases is:
We have a courses resource, if the teacher tries to DELETE a course with enrolled users, we return a 400 Cannot delete course with students response.

[Aymeric Augustin]

I'd like to stop seeing pull requests about this.

If you want to do it, this is how: ​https://github.com/django/django/pull/1154

[Aymeric Augustin <aymeric.augustin@…>]

In cb86f707a04e5635817d5f37a1443f9bf7d6af21:

Fixed #12747 -- Made reason phrases customizable.