Yeah. I'm just not sure how much benefit in terms of data transfer this will save. Has anyone tested this to see if this is even worth it?
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Erik Hatcher <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Thursday, October 30, 2008 9:54:28 AM > Subject: Re: replication handler - compression > > +1 - the GzipServletFilter is the way to go. > > Regarding request handlers reading HTTP headers, yeah,... this will improve, > for > sure. > > Erik > > On Oct 30, 2008, at 12:18 AM, Chris Hostetter wrote: > > > > > : You are partially right. Instead of the HTTP header , we use a request > > : parameter. (RequestHandlers cannot read HTP headers). If the param is > > > > hmmm, i'm with walter: we shouldn't invent new mechanisms for > > clients to request compression over HTTP from servers. > > > > replicatoin is both special enough and important enough that if we had to > > add special support to make that information available to the handler on > > the master we could. > > > > but frankly i don't think that's neccessary: the logic to turn on > > compression if the client requests it using "Accept-Encoding: gzip" is > > generic enough that there is no reason for it to be in a handler. we > > could easily put it in the SolrDispatchFilter, or even in a new > > ServletFilte (i'm guessing iv'e seen about 74 different implementations of > > a GzipServletFilter in the wild that could be used as is. > > > > then we'd have double wins: compression for replication, and compression > > of all responses generated by Solr if hte client requests it. > > > > -Hoss
