Perform HEAD request before GET

[Kikobeats]

I noted the library is doing a GET request to determinate if the url is reachable:

https://github.com/sindresorhus/is-reachable/blob/master/index.js#L16

Normally you can use HEAD request for doing that, but some sites disable perform this request over his sites.

I found this user case in the past and my solution was to try to perform a HEAD request first, fallback into GET if is not possible:

https://github.com/urlint/url-code-status/blob/master/index.js#L16

Because HEAD is lightweight GET, make sense if you want to accept a PR improving that?

[sindresorhus]

Sure, makes sense. PR welcome.

[silverwind]

Keep in mind that not all HTTP servers will support HEAD requests. If you want to speed up things, I suggest switching to core {http,https}.get and opt to not parse the response body.

[Kikobeats]

That's a good point!

HEAD and GET will be launched on parallel and the response will be the first request to be resolved.

Because got is using http/https internally, we can avoid parsing body as you suggest 🙂

[silverwind]

HEAD and GET will be launched on parallel

That seems pretty wasteful of resources to me, not sure I like it.

Because got is using http/https internally, we can avoid parsing body as you suggest

Doesn't got always parse the body unconditionally?

[Kikobeats]

That seems pretty wasteful of resources to me, not sure I like it.

I understand your point and I did tests based on this premise. Sometimes HEAD response is fastest than GET. In the case HEAD is not supported, it doesn't be done. Need to test it again disabling parse body response.

Doesn't got always parse the body unconditionally?

got accepts http request as options. I don't know how exactly specify about doesn't parse response (maybe @sindresorhus help here could be useful!). The point why I want to use got is to have the rest of the library benefits, like follow redirects

[silverwind]

The point why I want to use got is to have the rest of the library benefits, like follow redirects

We don't actually need to follow redirects in all cases. Part of the purpose of the checkRedirection function is to make an attempt at detecting captive portals that are realized through HTTP redirects. For this case, we should not follow a redirect (as detection can be done based on the response to the first request alone), for all others we shoud.

So in summary:

1. Issue node http(s) GET
2. If response is a redirect to a router ip, return false
3. If response code is not 3xx, return true, otherwise issue more GETs and possibly also HEADs, following redirects.

Also keep in mind that got does not support proxies. I've been using request with request-promise-native lately because of that, maybe you should do that here too.

[Kikobeats]

I noted got@9 accepts a null as encoding value for avoiding parse the response data: https://github.com/sindresorhus/got#encoding

Could this change in the codebase make an improvement as you suggest? #25 (comment)?

btw, this library needs to upgrade got dependency