2

For HEAD requests, Rails seems to perform all the usual steps including rendering templates and then discards the respective output (sends back an empty response).

I can't think of any way that rendering templates in case of a HEAD request makes any sense (unless you have some actual business logic that gets executed in the templates, but that should never be the case).

So my question would be: Do you agree with me or are there any possible side-effects I didn't foresee?

The reason I'm asking is because I'm thinking of filing a Rails issue and possibly submit a pull request for a feature which disables default (non-explicit) template rendering for HEAD requests.

sudoremo
  • 2,274
  • 2
  • 22
  • 39
  • I agree with you... But I have a doubt about `Content-Length`. I don't know if it's correct to set it to 0 for head. If you must calculate that, then you need to render the body. Update: [Here's more information](https://stackoverflow.com/questions/3854842/content-length-header-with-head-requests) – collimarco Feb 28 '20 at 11:45

1 Answers1

2

Good point Remo, however, I am not completely agree.

For every http verb, we manually need to write code to handle things. Similar thing with HEAD. HEAD request will follow execution style of GET request unless we don't handle it.

An example can be:

def index
  if request.head?
    head :created
  else
    # handle GET request
    Rails.logger.info "Derp #{request.method}"
  end
end
RAJ
  • 9,697
  • 1
  • 33
  • 63
  • You are right, but there is one implicit difference already: The response is empty. I think this might be done by the rack middleware? – sudoremo Jul 23 '15 at 11:25
  • Yes, it can be a good addition, however, Rails provides liberty to handle your verbs. Eg.: You can create records even with GET request. You can return object(may be json) from POST method, while it could be just `201/ok`. Verbs are only a way that how the data travels over HTTP. Just my opinion. :) – RAJ Jul 23 '15 at 11:32