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