Hoss, You are partially right. Instead of the HTTP header , we use a request parameter. (RequestHandlers cannot read HTP headers). If the param is present it wraps the response in an zip outputstream. It is configured in the slave because Every slave may not want compression. . Slaves which are near can skip it.
On Thu, Oct 30, 2008 at 3:54 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > My understanding of Noble's comment (and i could be wrong, i'm reading > between the lines) is that if you specify the new setting he's suggesting > when initializing the replication handler on the slave, then the slave > should start using an "Accept-Encoding: gzip" header when querying the > master, and that when recieving this header, the master will start > wrapping the response in a "Content-Encoding: gzip" > > (I'm making this assumption based on his note about this being a new slave > config option, with no mention of any new otions on the master) > > : You propose to do compressed transfers over HTTP ignoring the standard > : support for compressed transfers in HTTP. Programming that with a > : library doesn't make it "standard". > > : >> open a JIRA issue. we > : > will use a gzip on both ends of the pipe . On > : > the slave > : >> side you can > : > say > : > <str name="zip">true<str> > : > as an extra option to compress and > : >> send > : > data from server > : > --Noble > > > -Hoss > > -- --Noble Paul
