Inconsistent behavior of HEAD method

Support Bug
1

According to the HTTP 1.1 HEAD method spec, this method should have the same behavior as GET.

However, on a freshly started Stardog server (v4.2.3), that is not the case:

$ curl -XHEAD -v http://localhost:5820
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
* Rebuilt URL to: http://localhost:5820/
*   Trying ::1...
* Connected to localhost (::1) port 5820 (#0)
> HEAD / HTTP/1.1
> Host: localhost:5820
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: BASIC realm="Stardog"
< Content-Length: 0
<
* Connection #0 to host localhost left intact

$ curl -XGET -v http://localhost:5820
Note: Unnecessary use of -X or --request, GET is already inferred.
* Rebuilt URL to: http://localhost:5820/
*   Trying ::1...
* Connected to localhost (::1) port 5820 (#0)
> GET / HTTP/1.1
> Host: localhost:5820
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 2389
< Date: Wed, 03 May 2017 09:50:27 GMT
< Expires: Wed, 10 May 2017 09:50:27 GMT
< Cache-Control: private, max-age=604800
< Last-Modified: Tue, 17 Jan 2017 15:11:06 GMT
< Connection: keep-alive
< Content-Type: text/html
<
<!DOCTYPE html>
<html lang="en" class="no-js">
...
</html>
* Connection #0 to host localhost left intact
2

Hi,

You have actually stumbled upon a weird edge case, specifically for requests to the root of the server. When you perform a GET to http://localhost:5820/ it will assume you're a browser and serve you the admin web console. There is no authentication needed for that, in fact the HTML being returned is the page into which you would put your credentials to log in. Anything that isn't a GET to the root (including a HEAD to the root) needs credentials, hence the 401 you're receiving. If you were credentialed, you would actually get a 404 from that request.

That said, we do not fully support HEAD on all of our REST API. It's supported and implemented in the SPARQL Graph Store Protocol, so if you are attempting to use it as some kind of heartbeat or health check, you can HEAD http://localhost:5820/myDb?default and it will return the proper response.