On Jul 7, 10:52 pm, Andrew Fong <fongand...@gmail.com> wrote:
> 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?

Yes, but it is Apache that does what is needed, not mod_wsgi.

Graham

> -- 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to