The exception is very definitely being raised by me trying to
distinguish things based on REQUEST_METHOD type. Here's the traceback:
Traceback (most recent call last):
File "/usr/lib/python2.6/dist-packages/django/core/handlers/base.py",
line 92, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/home/andrew/djprj/helpers/request_handler.py", line 77, in
__call__
raise NoMethodError(request.method)
NoMethodError: The HEAD method is not allowed for this path
----
The relevant code in helpers/request_handler.py is this:
class RestHandler(object):
def __call__(self, request, *args, **kwargs):
method = request.method.upper()
if hasattr(self, method):
return getattr(self, method)(request, *args, **kwargs)
raise NoMethodError(request.method)
class NoMethodError(Exception):
def __init__(self, method):
super(Exception, self).__init__(
"The %s method is not allowed for this path" % method)
---
Graham, are you suggesting that if I receive a HEAD request, I should
behave exactly the same as if I received a GET request? That is, I
should assume Apache / mod_wsgi will take care of translating my
response into one appropriate for a HEAD request?
-- Andrew
On Jul 6, 7:28 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> On Jul 7, 2:14 am, Andrew Fong <fongand...@gmail.com> wrote:
>
> > Thanks for the response. I'm using Apache/mod_wsgi and getting error
> > messages in production because my handlers don't know how to handle a
> > HEAD request. If the server is supposed to automatically translate the
> > HEAD requests into GETs, then I probably have something set up
> > incorrectly. Any idea where to start looking?
>
> As I described, it doesn't always translate HEAD to GET and that
> shouldn't matter. Neither should it really matter in the Django layers
> either. If you in your code are trying to distinguish things based on
> REQUEST_METHOD type, then it is more likely to be in your code.
>
> I would suggest you post the Python traceback so others can say
> whether it is an issue in Django layers to eliminate that, and then
> perhaps point at where problem may lie. Ie., in your code or
> elsewhere.
>
> Graham
>
>
>
> > -- Andrew
>
> > On Jul 2, 7:16 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> > wrote:
>
> > > On Jul 3, 4:55 am, Andrew Fong <fongand...@gmail.com> wrote:
>
> > > > How exactly should I handle a HEAD request in Django?
>
> > > > So ... assuming my view looks like this...
>
> > > > def handle_request(request):
> > > > if request.method == 'POST': return do_post(request)
> > > > elif request.method == 'GET': return do_get(request)
> > > > elif request.method == 'HEAD': return do_head(request)
>
> > > > ... what should the do_head method return? The W3 standard says "The
> > > > HEAD method is identical to GET except that the server MUST NOT return
> > > > a message-body in the response".
>
> > > > How exactly do I not return a message body though? Do I just return
> > > > None? Do I return the response I would for a GET and then modify it
> > > > somehow?
>
> > > You generally don't need to do anything different, the standard says
> > > 'the ***server***'.
>
> > > So, for sane web servers, the underlying server will deal with this
> > > and the application doesn't need to. You should just do exactly what
> > > you would normally do for a GET request. The web server would then
> > > return all the headers but just throw the response content away and
> > > not return it to the client.
>
> > > If you do act differently, you potentially break the requirement that
> > > response headers for the HEAD should match what would be returned for
> > > a GET request against same resource. Thus, the suggestion of returning
> > > an empty string could stuff up returned content length for a start.
>
> > > FWIW, in Apache/mod_wsgi it will deliberately at times translate a
> > > HEAD into a GET when it is passed into the WSGI application. This will
> > > occur when there are Apache output filters registered that may want to
> > > change response headers and modify the content. For example,
> > > mod_deflate, which would compress the response. If this isn't done and
> > > the application acted differently for a HEAD, then the data received
> > > by Apache output filter would not be the same as for the GET and
> > > result returned to client would be different than what it should be.
>
> > > Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
