Feature Proposal: Proper HEAD Request Path

[tburghart]

At present, HEAD requests are really just GETs with the object value stripped out at the edge.
With larger object sizes, this is unduly expensive.

Similarly, DELETE operations perform a GET, essentially for nothing but the vclock, which would be much lighter weight utilizing a streamlined HEAD operation.

This proposal aims to sort out what the riak_client API for head/? should look like, and whether it should be implemented through riak_kv_get_fsm (likely?) or a new mechanism.

[martinsumner]

One complication is that the HEAD response in HTTP is expected to include all metadata including the content length - https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/HEAD. I think I've considered a quick fix in the past, but this complicated matters - though I'm not clear if this is a strict requirement of the HTTP standard. I'm not sure as well how we might be constrained by expectations of the webmachine workflow.

I agree though, there are a lot of requirements where a HEAD is sufficient, and I think most developers would expect it to be implemented more efficiently than requesting a GET.

Eventually we need to switch the GET gen_fsm to be a gen_statem (or even a gen_server). This might be an excuse to make this happen.

[aef-]

This was discussed a little while ago so just adding here for posterity.

GET/HEAD must return the same Content-Length for a given request if the Content-Length is set. This value reflects the possibly compressed object body. So an implementation could require I/O just to throw it away and the savings are only network bandwidth.

So I don't think there's an alternative to what Martin's doing with Leveled. At the very least we should just use the same name among back-ends and make it a system-level metadata if it isn't already.

[martinsumner]

Rather than worry about the constraints of HTTP standard, a HEAD request could be implemented as a GET request parameter e.g.

GET /types/SampleType/buckets/SampleBucket/keys/SampleKey?head_only=true

So this would allow us in a standards-compliant way to return an empty value with no content-length, and just the object metadata.

[aef-]

It'll be less work to send HEAD without Content-Length which is compliant with the HTTP standard.

[martinsumner]

Sorry, I think I've got confused over whether the Content-Length is required in a HEAD response. I thought it was, but I think you are right that it isn't.

Checked the RFC, and payload header fields MAY be omitted - and the Content-Length is such a field.

So ignore my previous comments, this can be just done with a HEAD request in a compliant way. But even when the size is available, it should not be included as the Content Length - as this would not match and so not be compliant. Is this is what you're saying @aef- ?

Am I now on the same page? If so, thanks, and sorry for getting mixed up.

[aef-]

My apologies, I should have elaborated. But that's correct.

If the client makes a request with Accept-Encoding: gzip, and for GETs we return Content-Encoding: gzip, we must do this for HEADs. Content-Length will reflect the gzip'd value being sent, not the actual size of the value as it's stored (unless it's already gzip'd).

[martinsumner]

Note this issue may be handled to some extent by OpenRiak/riak_kv#119