HTTP interface questions

Justin Sheehy justin at
Thu Jan 7 16:33:56 EST 2010

Hi, Paul.

On Thu, Jan 7, 2010 at 4:18 PM, Paul Rogers <paul at> wrote:

>  1. Why can I not do HTTP HEAD for a resource via the raw interface like I can
>    for a resource via the jiak interface? Seems that would be equal
>    functionality. I use HEAD to test existence of a resource via Jiak and
>    would like to the same for the raw interface.

You most certainly can.  Proof by example:

$ curl -I
HTTP/1.1 200 OK
X-Riak-Vclock: a85hYGBgzGDKBVIsbH/suDOYEhnzWBmUz+46wpcFAA==
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.5.1 (hack the charles gibson)
Link: </raw/hi_paul>; rel="up"
Last-Modified: Thu, 07 Jan 2010 21:24:51 GMT
ETag: 2F1HXpquhABHIDcfbO4lEa
Date: Thu, 07 Jan 2010 21:26:33 GMT
Content-Type: text/plain
Content-Length: 2888

>  2. Why is the HTTP Header for the Riak vclock value X-JIAK-VClock via the jiak
>    interface and X-RIAK-VClock via the raw interface? I'd like to parse
>    against the same string to get the vclock from the HTTP headers.

Fair enough.  There's no reason we couldn't change the Jiak one to
match the raw one, assuming we decide to keep Jiak.  More and more
users have been discovering that the raw resource approach works
better for them in multiple ways, and so (once we have a chance to
ensure that we have very good documentation for use of the raw
interface) we may slowly deprecate it.  It's easy to switch an app
from jiak to raw, and not much you can do with jiak that raw doesn't
work fine for.

>  3. What is the purpose of the HTTP response header Link field on a GET request
>    against a bucket URL when the keys are returned?

The Link header allows an HTTP client that is aware of the Link
specification (
and an update to the Atom protocol) to navigate to the documents in a
bucket without knowing anything about the content type of the body.

I hope that this was helpful.



More information about the riak-users mailing list