# Sending POST data via a memcache GET request

**URL:** <https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737>\
**Category:** Elasticsearch\
**Created:** [November 1, 2011, 6:54pm UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737 "2011-11-01T18:54:55Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Greg\_Slovacek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/greg_slovacek/32/3090_2.png) [@Greg\_Slovacek](https://discuss.elastic.co/u/Greg_Slovacek)\
**Post date:** [November 1, 2011, 6:54pm UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737/1 "2011-11-01T18:54:55Z")

</div>

I'm evaluating ElasticSearch to see if its features and performance  
will suit our needs for a search backend as we expand our search  
product. First of all, congratulations on building a component that  
was shockingly easy to get started with!

I'd like to use the memcached module to talk to our elastic search  
backend since I can then drop it in place of our current one. This  
leaves me with one question: how can I make a GET request that does a  
Search other than a query\_string search, given that I can't provide  
post data? Is there an undocumented URL parameter (e.g. "source") I  
can use that will contain the JSON post body?

Also, you might consider extending the module to support the CAS  
command, which could be equivalent to a GET with a body. If we decide  
to continue using elasticsearch via the memcache module I may be able  
to help you guys with that. 🙂

Thanks,

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [November 1, 2011, 7:14pm UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737/2 "2011-11-01T19:14:25Z")

</div>

Its been a long time since I wrote the memcached module, but yes, you can  
provide source as a URL parameter when you search. Though, I would suggest  
using the HTTP transport, as its gone through a more thorough testings.

On Tue, Nov 1, 2011 at 8:54 PM, Greg Slovacek [greg@asana.com](mailto:greg@asana.com) wrote:

> I'm evaluating Elasticsearch to see if its features and performance  
> will suit our needs for a search backend as we expand our search  
> product. First of all, congratulations on building a component that  
> was shockingly easy to get started with!
> 
> I'd like to use the memcached module to talk to our Elasticsearch  
> backend since I can then drop it in place of our current one. This  
> leaves me with one question: how can I make a GET request that does a  
> Search other than a query\_string search, given that I can't provide  
> post data? Is there an undocumented URL parameter (e.g. "source") I  
> can use that will contain the JSON post body?
> 
> Also, you might consider extending the module to support the CAS  
> command, which could be equivalent to a GET with a body. If we decide  
> to continue using elasticsearch via the memcache module I may be able  
> to help you guys with that. 🙂
> 
> Thanks,

---

<div class="post-metadata">

**Author:** ![Greg\_Slovacek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/greg_slovacek/32/3090_2.png) [@Greg\_Slovacek](https://discuss.elastic.co/u/Greg_Slovacek)\
**Post date:** [November 1, 2011, 11:29pm UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737/3 "2011-11-01T23:29:57Z")

</div>

This would appear to work, though the main problem is that the  
memcache protocol specifies a key length of \<250 characters, so it's  
not really a good idea to send a sizable query request even in a URL  
like that. My particular memcache client implementation crashes in  
this case. 🙂 I could try to use another, but I also think usage of  
the memcache module should at least stick to the wire-level  
constraints of the protocol.

Would there be opposition to me adding the CAS instruction as I  
described? This will behave the same as a GET request but will use the  
data provided. There's no real equivalent semantic for CAS (check-and-  
set) in the HTTP protocol (this would be PUT with special headers for  
validation, I guess) so it seems reasonable to co-opt its here to make  
the API more complete. Do you agree?

Thanks,

On Nov 1, 12:14 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:

> Its been a long time since I wrote the memcached module, but yes, you can  
> provide source as a URL parameter when you search. Though, I would suggest  
> using the HTTP transport, as its gone through a more thorough testings.
> 
> On Tue, Nov 1, 2011 at 8:54 PM, Greg Slovacek [g...@asana.com](mailto:g...@asana.com) wrote:
> 
> > I'm evaluating Elasticsearch to see if its features and performance  
> > will suit our needs for a search backend as we expand our search  
> > product. First of all, congratulations on building a component that  
> > was shockingly easy to get started with!
> 
> > I'd like to use the memcached module to talk to our Elasticsearch  
> > backend since I can then drop it in place of our current one. This  
> > leaves me with one question: how can I make a GET request that does a  
> > Search other than a query\_string search, given that I can't provide  
> > post data? Is there an undocumented URL parameter (e.g. "source") I  
> > can use that will contain the JSON post body?
> 
> > Also, you might consider extending the module to support the CAS  
> > command, which could be equivalent to a GET with a body. If we decide  
> > to continue using elasticsearch via the memcache module I may be able  
> > to help you guys with that. 🙂
> 
> > Thanks,

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [November 2, 2011, 6:30pm UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737/4 "2011-11-02T18:30:57Z")

</div>

On Wed, Nov 2, 2011 at 1:29 AM, Greg Slovacek [greg@asana.com](mailto:greg@asana.com) wrote:

> This would appear to work, though the main problem is that the  
> memcache protocol specifies a key length of \<250 characters, so it's  
> not really a good idea to send a sizable query request even in a URL  
> like that. My particular memcache client implementation crashes in  
> this case. 🙂 I could try to use another, but I also think usage of  
> the memcache module should at least stick to the wire-level  
> constraints of the protocol.
> 
> Would there be opposition to me adding the CAS instruction as I  
> described? This will behave the same as a GET request but will use the  
> data provided. There's no real equivalent semantic for CAS (check-and-  
> set) in the HTTP protocol (this would be PUT with special headers for  
> validation, I guess) so it seems reasonable to co-opt its here to make  
> the API more complete. Do you agree?

I remember looking at CAS back when I wrote the memcached protocol, and it  
did not fit a request that can both get a payload, and send a payload as a  
response. But, I might have missed something, so definitely, I am open to  
it.

> Thanks,
> 
> On Nov 1, 12:14 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote:
> 
> > Its been a long time since I wrote the memcached module, but yes, you can  
> > provide source as a URL parameter when you search. Though, I would  
> > suggest  
> > using the HTTP transport, as its gone through a more thorough testings.
> > 
> > On Tue, Nov 1, 2011 at 8:54 PM, Greg Slovacek [g...@asana.com](mailto:g...@asana.com) wrote:
> > 
> > > I'm evaluating Elasticsearch to see if its features and performance  
> > > will suit our needs for a search backend as we expand our search  
> > > product. First of all, congratulations on building a component that  
> > > was shockingly easy to get started with!
> > 
> > > I'd like to use the memcached module to talk to our Elasticsearch  
> > > backend since I can then drop it in place of our current one. This  
> > > leaves me with one question: how can I make a GET request that does a  
> > > Search other than a query\_string search, given that I can't provide  
> > > post data? Is there an undocumented URL parameter (e.g. "source") I  
> > > can use that will contain the JSON post body?
> > 
> > > Also, you might consider extending the module to support the CAS  
> > > command, which could be equivalent to a GET with a body. If we decide  
> > > to continue using elasticsearch via the memcache module I may be able  
> > > to help you guys with that. 🙂
> > 
> > > Thanks,

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:50am UTC](https://discuss.elastic.co/t/sending-post-data-via-a-memcache-get-request/5737/5 "2017-07-06T03:50:05Z")

</div>