I'm interested to know why you're trying to store an empty body in Riak. Surely 
just don't even make the request to Riak? I guess I could be overlooking 
something obvious.

Sam
--  
Sam Elliott
Engineer
[email protected]
--


On Tuesday, 10 September 2013 at 6:29PM, Vincenzo Vitale wrote:

> Hi Sam,
> thanks for the fast reply.
>  
> In my company we normally use your third suggestion and indeed it's a robust 
> strategy.
>  
> At the moment we are relying on a riak client based on spray 
> (https://github.com/agemooij/riak-scala-client) so even if we set the 
> Content-Type - when the body is empty - it doesn't get to the final request 
> being dispatched.  
>  
> Our workaround is to have a content body equal to the one byte carriage 
> return.
> It's not a big deal...
>  
> Writing to the mailing list was mainly because curious to know your thoughts 
> about this :)
>  
>  
> Have a good day,
> V.
>  
>  
>  
> On Wed, Sep 11, 2013 at 12:03 AM, Sam Elliott <[email protected] 
> (mailto:[email protected])> wrote:
> > The content-type is important for Riak KV: Various clients will use it to 
> > identify the difference between a response where the whole body is the key, 
> > or a response that contains siblings (if you have allow_mult=true).
> >  
> > I suggest finding or creating a content type, so that this is clearer to 
> > your app. It will also allow you to version your objects better. Here are a 
> > few suggestions (of course replace the text between the < >):
> > - application/octet-stream - this is usually used for binary data, and is 
> > the easiest thing to set the content-type to.
> > - application/vnd.<company name>.<useful type name here> - a 
> > vendor-specific type, which you can create yourself
> > - application/vnd.<company name>.<useful type name here>.v<version number> 
> > - another vendor-specific type, which supports versioning.
> >  
> > You don't have to use the information in your final app, but it is used by 
> > riak and riak clients, so that's why we require it.
> >  
> > --
> > Sam Elliott
> > Engineer
> > [email protected] (mailto:[email protected])
> > --
> >  
> >  
> > On Tuesday, 10 September 2013 at 5:03PM, Vincenzo Vitale wrote:
> >  
> > > Suppose I want to just store keys in a bucket without any body, this make 
> > > sense in scenarios where the key completely identify the entity. Is it 
> > > possible to use the riak http api without including the content-type 
> > > header?
> > > Looking at the http specifications, content–type is not mandatory or 
> > > suggested when the body is empty:
> > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1
> > > and it's probably a good argument to say that if the entity message is 
> > > empty then the content type doesn't really make sense.
> > > Personally I think that just the existence of an http entity - body or 
> > > not body – is sufficient to justify a "type"; it's unfortunate that any 
> > > other higher type (entity type maybe?) - decoupled from what is defined 
> > > as content - exist in the spec.
> > > Framework like spray are quite strict about this, not setting any content 
> > > type when the content is empty:
> > > https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/HttpEntity.scala#L74
> > > how to deal with such situation? Adding a fake content because of this 
> > > data store constraint doesn't seems right.
> > >  
> > >  
> > > Thanks,
> > > Vincenzo.
> > >  
> > > --
> > > If your e-mail inbox is out of control, check out 
> > > http://sanebox.com/t/mmzve. I love it.
> > > _______________________________________________
> > > riak-users mailing list
> > > [email protected] (mailto:[email protected]) 
> > > (mailto:[email protected])
> > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >  
>  
>  
>  
>  
> --  
> If your e-mail inbox is out of control, check out http://sanebox.com/t/mmzve. 
> I love it.




_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to