Hapi: Request support for HEAD routes

[fredrikwidlund]

In the case that a GET verb is expensive, HEAD is very useful to check the existence of a REST resource.

[hueniverse]

HEAD is created automatically for every GET you define. Are you asking to define them separately?

[fredrikwidlund]

Yes.

F

On Fri, Apr 26, 2013 at 6:13 PM, Eran Hammer [email protected]:

HEAD is created automatically for every GET you define. Are you asking to
define them separately?

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17084121
.

[fredrikwidlund]

Or at least to be able to hook onto the automatically created one.

On Friday, April 26, 2013, Fredrik Widlund wrote:

Yes.

F

On Fri, Apr 26, 2013 at 6:13 PM, Eran Hammer <[email protected]

wrote:

HEAD is created automatically for every GET you define. Are you asking to
define them separately?

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17084121
.

[hueniverse]

What do you mean "hook onto"? I can allow you to define your own, and if none defined, just call GET and drop the payload.

[fredrikwidlund]

That would work great for me.

On Saturday, April 27, 2013, Eran Hammer wrote:

What do you mean "hook onto"? I can allow you to define your own, and if
none defined, just call GET and drop the payload.

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17104012
.

[hueniverse]

After thinking about it for a bit, I decided not to support adding HEAD routes directly. If you want to optimize your handling of HEAD requests, simply check your GET handler for the method, and if it is 'head', return an empty response with the correct headers. This is only worth doing for some very expensive GET requests, where you are expecting clients to use HEAD directly.

The main reason not to support it, is that I am expecting very few developers to use this, but it will add an extra lookup for every HEAD request.

[fredrikwidlund]

All right, slightly less transparent but that works for me, didn't think
about that. Indeed the GET I'm thinking about includes serializing a very
large JSON object so it is indeed expensive. Thanks.

On Sun, Apr 28, 2013 at 8:35 PM, Eran Hammer [email protected]:

After thinking about it for a bit, I decided not to support adding HEAD
routes directly. If you want to optimize your handling of HEAD requests,
simply check your GET handler for the method, and if it is 'head', return
an empty response with the correct headers. This is only worth doing for
some very expensive GET requests, where you are expecting clients to use
HEAD directly.

The main reason not to support it, is that I am expecting very few
developers to use this, but it will add an extra lookup for every HEAD
request.

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17139883
.

[hueniverse]

Keep in mind that a proper HEAD should return the content-length of the GET payload. So you might still need to figure out the size of the payload even if you are not serializing it. A Better solution for probing for an API is using OPTIONS, we like HEAD is provided for you, but unlike HEAD, you can override with your own OPTIONS handler.

[fredrikwidlund]

Content-length using head is not strictly required, and for example
google.com will not give you one. Not sure I would like options semantics
better to check for existence. Is it not possible to skip content-length in
the reply using hapi?

On Mon, Apr 29, 2013 at 2:16 AM, Eran Hammer [email protected]:

Keep in mind that a proper HEAD should return the content-length of the
GET payload. So you might still need to figure out the size of the payload
even if you are not serializing it. A Better solution for probing for an
API is using OPTIONS, we like HEAD is provided for you, but unlike HEAD,
you can override with your own OPTIONS handler.

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17145816
.

[hueniverse]

hapi doesn't isolate header construction from payload construction. So it has no way of knowing what parts of the handler are relevant to a HEAD.

[fredrikwidlund]

You could add an .override({Content-length: ''}) to the reply object?

On Mon, Apr 29, 2013 at 5:25 AM, Eran Hammer [email protected]:

hapi doesn't isolate header construction from payload construction. So it
has no way of knowing what parts of the handler are relevant to a HEAD.

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17148753
.

[hueniverse]

What for?

[fredrikwidlund]

I was assuming that hooking on GET, checking method == HEAD, and returning
an empty body will result in Content-length: 0, or I misunderstood your
mail above and I can indeed set or remove it (Content-length) from the
headers.

On Mon, Apr 29, 2013 at 10:20 AM, Eran Hammer [email protected]:

What for?

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17154660
.

[hueniverse]

Yes, that's correct. You can just use the generic response header() method.

[fredrikwidlund]

Tried using headers but was unable to remove a header, and more
specifically it seems Content-Length is added later on so I am unable to
remove/set this.

On Mon, Apr 29, 2013 at 10:36 AM, Fredrik Widlund [email protected]

wrote:

I was assuming that hooking on GET, checking method == HEAD, and returning
an empty body will result in Content-length: 0, or I misunderstood your
mail above and I can indeed set or remove it (Content-length) from the
headers.

On Mon, Apr 29, 2013 at 10:20 AM, Eran Hammer [email protected]:

What for?

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17154660
.

[hueniverse]

Why are you trying to remove headers?

[fredrikwidlund]

Because returning a "Content-length: 0" should not be part of a HEAD reply.

On Tue, Apr 30, 2013 at 5:50 PM, Eran Hammer [email protected]:

Why are you trying to remove headers?

—
Reply to this email directly or view it on GitHubhttps://github.com/spumko/hapi/issues/795#issuecomment-17235641
.

[hueniverse]

Let me think about this one.

[hueniverse]

Closed by 08c39ceb95b169a65b2a4d42ed4dbc6099516124.

[vitaliyAtSvarog]

Guis i need HEAD to, for implementing tus.io protocol server based on hapijs. https://github.com/tus/tus-node-server - see example here.

[ThisIsMissEm]

As far as I know, HEAD is just GET but with the instruction to return headers only, and not the body of the response.

On 4 Jul 2016, at 11:20, vitaliyAtSvarog [email protected] wrote:

Guis i need HEAD to, for implementing tus.io protocol server based on hapijs. https://github.com/tus/tus-node-server https://github.com/tus/tus-node-server - see example here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/hapijs/hapi/issues/795#issuecomment-230245183, or mute the thread https://github.com/notifications/unsubscribe/AAB4a_sstnQ38ijZUNBmg4gXpuAzqLveks5qSNBKgaJpZM4AnIJw.

[jishi]

Saying that HEAD is just a GET without body is an oversimplification. The main usage of HEAD is to check for content freshness, and rarely includes the same logic as the actual GET in itself. To me it would make sense to at least allow one to separate them easily and more clearly than by checking the verb manually in the GET header.

True though that it at least is possible, but gives you a very ugly code path and looks more like a hack rather than something you want to do.

[zyrorl]

I think closing this ticket is the wrong way of approaching this. There should be a way to add HEAD requests, and if a "GET" also creates a "HEAD", then this should be overridden by config, or at least over-written when one is separately specified.

[hueniverse]

The issue is whether this use case justifies adding the lookup complexity for every head request to first check for a custom override before looking up the GET route. I decided it is not worth it. Between your code being a tiny bit ugly to everyone else's run time performing additional look ups, I choose the former.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.