New feature: HTTP OPTIONS and improved HEAD for View

[Steven Cummings]

I'd like to propose some simple improvements to django.views.generic.base.View:

1. To complement the automatic HTTP 405 response, provide a default implementation of the HTTP OPTIONS method. This default response would have an HTTP 204 NO CONTENT status and include an Allow response header just like that of the 405 response (django.http.HttpResponseNotAllowed). Developers could easily override this method to provide more info about endpoint or server capabilities.

2. Improve the default HTTP HEAD handler by ensuring it has a blank body, as this is the expectation of a response to a HEAD request. Also, there should be consideration for the GET handler not existing, which should result in a 405. The code appears to assume it exists, which would result in an AttributeError instead.

If these are generally agreed upon I'll supply the patch.

--
Steven

[Jamie Matthews]

> 2. Improve the default HTTP HEAD handler by ensuring it has a blank body,
> as this is the expectation of a response to a HEAD request. Also, there
> should be consideration for the GET handler not existing, which should
> result in a 405. The code appears to assume it exists, which would result
> in an AttributeError instead.

For previous discussion on this, see this ticket:
https://code.djangoproject.com/ticket/15668

* Graham Dumpleton disagrees with your first point: "Python web
applications should never themselves discard the response content for
HEAD requests. They should always return the request content and allow
the underlying WSGI server or hosting web server to discard the
request content."

* My original implementation of the "head" method on the View base
class [1] *did* check whether the view already has a "get" method.
This was later changed in [2] to the current semantics which, I agree,
looks a bit wrong. Perhaps we should revert to the original behaviour?

[1] https://github.com/django/django/commit/c7fe43
[2] https://github.com/django/django/commit/760d0f

[Steven Cummings]

On Sun, Nov 27, 2011 at 4:17 PM, Jamie Matthews <jamie.m...@gmail.com> wrote:

> 2. Improve the default HTTP HEAD handler by ensuring it has a blank body,
> as this is the expectation of a response to a HEAD request. Also, there
> should be consideration for the GET handler not existing, which should
> result in a 405. The code appears to assume it exists, which would result
> in an AttributeError instead.

For previous discussion on this, see this ticket:
https://code.djangoproject.com/ticket/15668

* Graham Dumpleton disagrees with your first point: "Python web
applications should never themselves discard the response content for
HEAD requests. They should always return the request content and allow
the underlying WSGI server or hosting web server to discard the
request content."

Interesting. I hadn't taken the wsgi implementation into account. This seems to preclude app-servers from implementing HEAD with any shortcuts (e.g., cache the headers). Anyway, we'll leave this alone then...

 

* My original implementation of the "head" method on the View base
class [1] *did* check whether the view already has a "get" method.
This was later changed in [2] to the current semantics which, I agree,
looks a bit wrong. Perhaps we should revert to the original behaviour?

[1] https://github.com/django/django/commit/c7fe43
[2] https://github.com/django/django/commit/760d0f

Yeah, that implementation seems preferable. What was the reason for backing it out?

[Jamie Matthews]

> Yeah, that implementation seems preferable. What was the reason for backing
> it out?

Not sure. What would be the procedure for getting this changed? Open a
new ticket, I assume?

[Steven Cummings]

I assumed I needed the votes here to get going on that. In the past when I've started with a ticket I've been directed here to gather support first.
--
Steven

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Jamie Matthews]

Just bumping this - can anyone suggest what the next steps should be?
It'd be nice to get it fixed for 1.4.

Thanks,

Jamie

[Steven Cummings]

I'll probably go ahead and log it and start the patch soon. Your feedback on truncation for HTTP HEAD was helpful, and the rest doesn't seem very controversial.
--
Steven

[Steven Cummings]

Created a ticket with the patch: https://code.djangoproject.com/ticket/17449
--
Steven