... 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?
> ... 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?
> Thanks in advance!
> -- Andrew
You can just return a blank instance of HttpResponse. You can set
headers on it if you want but you don't have to pass in any content.
--
DR.
> ... 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.
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?
-- Andrew
On Jul 2, 7:16 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:
> > ... 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.
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.
> > > ... 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.
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...
> > > > ... 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.
> 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.
> 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...
> > > > > ... 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.
|
