Is there any reason to block HEAD requests?

Question

Apologies if this isn't the right place to ask this. I occasionally get alerts from my Django website along these lines:

Internal Server Error: /posts/specific-post/

UnboundLocalError at /posts/specific-post/ local variable 'comment_form' referenced before assignment

HEAD requests are triggering these errors. This is probably because my view code is structured like this:

if request.method == "POST":
    comment_form = CommentForm(request.POST)
    # handle the form ...
    # finally,
    return HttpResponseRedirect('/comment/')
else if request.method == "GET":
    comment_form = CommentForm()

context = {
    "comment_form": comment_form,
}

return render(request, 'detail.html', context)

The Django docs tend to use a simple if else, rather than if else if:

if request.method == "POST":
    # ...
else:
    # ...

So my question is this: Is there any reason why I shouldn't use the simple if else, and allow not only POST and GET requests, but all other types of requests (including ostensibly HEAD requests)? And more out of curiosity, are the HEAD requests from search engine indexers or something? Thanks for any advice.

Do these answer your question? https://security.stackexchange.com/questions/62811/should-i-disable-http-head-requests?rq=1 and https://security.stackexchange.com/questions/103540/is-there-any-reason-to-block-https?rq=1 — schroeder, Jul 02 '21 at 07:04

score 0 · Answer 1 · answered Jul 02 '21 at 21:05

As mentioned in the first link, HEAD can also be useful for web crawlers to determine if a page has changed since the last visit and whether it is worth retrieving. But since most pages tend to be dynamically generated these days, the cost for the server of serving the page is pretty much the same in HEAD than GET. But it helps reduce unnecessary traffic.

A good use case is crawling a website to detect broken (404) links, or building a sitemap.

If you have a live site exposed on the Internet I suggest to enable the method but check that the headers make sense for a search engine. If for example the last modified date is an arbitrary value that never changes, then the indication is not useful.

score -1 · Accepted Answer · answered Jul 02 '21 at 06:32

-1

No. HEAD is not dangerous.

The error is normal because you are not handling this HTTP verb (or any verb different to GET/POST). You can add an else and just return a 404 error or similar if you want.

HEAD is useful to know if a path exists or to get the Content-Length for download a file (or any other HTTP header). Thus the recommendation is handle HEAD and for other HTTP methods you do not need, just return the same response for all.

answered Jul 02 '21 at 06:32

sinkmanu

122
3

2

**Do not return a 404 on the HEAD request for a resource that does exist**, or it will break interactions with your visitors' browsers and search engine crawlers. You should return exactly the same headers as for a GET request, only without the message-body. Your server might already be automatically stripping the message-body on HEAD requests, then you could use the same methods as for GET. – René Roth Jul 03 '21 at 19:48

Is there any reason to block HEAD requests?

2 Answers2