Re: [basex-talk] Restxq handling accept-encoding
I should clarify that I’m asking about content negotiation. %rest:produces is described as constraining based on the Accept header. Should I explicitly look for Accept-Encoding and produce binary data that is in one of the requested compressed formats, or is there something in basex’s restxq implementation that does this? Kendall From: <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Kendall Shaw <kendall.shaw@workday.com> Date: Tuesday, November 15, 2016 at 4:58 PM To: BaseX <basex-talk@mailman.uni-konstanz.de> Subject: [basex-talk] Restxq handling accept-encoding To return compressed text data, should I explicitly look for Accept-Encoding and use java to deflate or gzip output of convert:binary-to-string(db:retrieve(…))? Kendall
Hi Kendall, This is usually handled by the web server (by default, Jetty). Maybe this helps? http://blog.max.berger.name/2010/01/jetty-7-gzip-filter.html Cheers, Christian On Wed, Nov 16, 2016 at 2:29 AM, Kendall Shaw <kendall.shaw@workday.com> wrote:
I should clarify that I’m asking about content negotiation. %rest:produces is described as constraining based on the Accept header. Should I explicitly look for Accept-Encoding and produce binary data that is in one of the requested compressed formats, or is there something in basex’s restxq implementation that does this?
Kendall
From: <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Kendall Shaw <kendall.shaw@workday.com> Date: Tuesday, November 15, 2016 at 4:58 PM To: BaseX <basex-talk@mailman.uni-konstanz.de> Subject: [basex-talk] Restxq handling accept-encoding
To return compressed text data, should I explicitly look for Accept-Encoding and use java to deflate or gzip output of convert:binary-to-string(db:retrieve(…))?
Kendall
Thank you. I’m using tomcat, not for any particular reason. There I added: compression=”on” compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" to the connector element in server.xml. For now, that’s good enough. Eventually, I’ll want to figure out how to store a compressed resource and serve that if compression is request. Kendall On 11/16/16, 1:45 AM, "Christian Grün" <christian.gruen@gmail.com> wrote: Hi Kendall, This is usually handled by the web server (by default, Jetty). Maybe this helps? https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.max.berger.name_201... Cheers, Christian On Wed, Nov 16, 2016 at 2:29 AM, Kendall Shaw <kendall.shaw@workday.com> wrote: > I should clarify that I’m asking about content negotiation. %rest:produces > is described as constraining based on the Accept header. Should I explicitly > look for Accept-Encoding and produce binary data that is in one of the > requested compressed formats, or is there something in basex’s restxq > implementation that does this? > > > > Kendall > > > > From: <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Kendall Shaw > <kendall.shaw@workday.com> > Date: Tuesday, November 15, 2016 at 4:58 PM > To: BaseX <basex-talk@mailman.uni-konstanz.de> > Subject: [basex-talk] Restxq handling accept-encoding > > > > To return compressed text data, should I explicitly look for Accept-Encoding > and use java to deflate or gzip output of > convert:binary-to-string(db:retrieve(…))? > > > > Kendall > >
So, to avoid having the web server compress content at runtime, it appears that I can do this: declare %rest:path('/test-binary') %rest:GET function w:test-binary() { web:response-header(map {'media-type': 'application/json'}, map {'Content-Encoding': 'gzip'}) , db:retrieve('test-binary', 'out.bin') }; where out.bin contains gzipped json text. I would then serve the gzipped resource if Accept-Encoding contains deflate or gzip and otherwise serve the text resource. Is there any problem with that approach? Kendall On 11/16/16, 10:35 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote: Thank you. I’m using tomcat, not for any particular reason. There I added: compression=”on” compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" to the connector element in server.xml. For now, that’s good enough. Eventually, I’ll want to figure out how to store a compressed resource and serve that if compression is request. Kendall On 11/16/16, 1:45 AM, "Christian Grün" <christian.gruen@gmail.com> wrote: Hi Kendall, This is usually handled by the web server (by default, Jetty). Maybe this helps? https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.max.berger.name_201... Cheers, Christian On Wed, Nov 16, 2016 at 2:29 AM, Kendall Shaw <kendall.shaw@workday.com> wrote: > I should clarify that I’m asking about content negotiation. %rest:produces > is described as constraining based on the Accept header. Should I explicitly > look for Accept-Encoding and produce binary data that is in one of the > requested compressed formats, or is there something in basex’s restxq > implementation that does this? > > > > Kendall > > > > From: <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Kendall Shaw > <kendall.shaw@workday.com> > Date: Tuesday, November 15, 2016 at 4:58 PM > To: BaseX <basex-talk@mailman.uni-konstanz.de> > Subject: [basex-talk] Restxq handling accept-encoding > > > > To return compressed text data, should I explicitly look for Accept-Encoding > and use java to deflate or gzip output of > convert:binary-to-string(db:retrieve(…))? > > > > Kendall > >
...should work! Am 18.11.2016 8:20 vorm. schrieb "Kendall Shaw" <kendall.shaw@workday.com>:
So, to avoid having the web server compress content at runtime, it appears that I can do this:
declare %rest:path('/test-binary') %rest:GET function w:test-binary() { web:response-header(map {'media-type': 'application/json'}, map {'Content-Encoding': 'gzip'}) , db:retrieve('test-binary', 'out.bin') };
where out.bin contains gzipped json text.
I would then serve the gzipped resource if Accept-Encoding contains deflate or gzip and otherwise serve the text resource.
Is there any problem with that approach?
Kendall
On 11/16/16, 10:35 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
Thank you. I’m using tomcat, not for any particular reason. There I added:
compression=”on” compressableMimeType="text/html,text/xml,text/plain,text/ css,text/javascript,application/javascript,application/json"
to the connector element in server.xml. For now, that’s good enough. Eventually, I’ll want to figure out how to store a compressed resource and serve that if compression is request.
Kendall
On 11/16/16, 1:45 AM, "Christian Grün" <christian.gruen@gmail.com> wrote:
Hi Kendall,
This is usually handled by the web server (by default, Jetty). Maybe this helps?
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog. max.berger.name_2010_01_jetty-2D7-2Dgzip-2Dfilter.html&d= DgIFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=JgwnBEpN1c-DDmq- Up2QMq9rrGyfWK0KtSpT7dxRglA&m=6JsUJinjuwLxS__1HSp55O2G4zm8DoUtTk-zEVzV8cQ& s=ZWuB0REriC5VtRp4dTHd-HoaJ70qXUAVfj49wV_AggI&e=
Cheers, Christian
On Wed, Nov 16, 2016 at 2:29 AM, Kendall Shaw < kendall.shaw@workday.com> wrote: > I should clarify that I’m asking about content negotiation. %rest:produces > is described as constraining based on the Accept header. Should I explicitly > look for Accept-Encoding and produce binary data that is in one of the > requested compressed formats, or is there something in basex’s restxq > implementation that does this? > > > > Kendall > > > > From: <basex-talk-bounces@mailman.uni-konstanz.de> on behalf of Kendall Shaw > <kendall.shaw@workday.com> > Date: Tuesday, November 15, 2016 at 4:58 PM > To: BaseX <basex-talk@mailman.uni-konstanz.de> > Subject: [basex-talk] Restxq handling accept-encoding > > > > To return compressed text data, should I explicitly look for Accept-Encoding > and use java to deflate or gzip output of > convert:binary-to-string(db:retrieve(…))? > > > > Kendall > >
participants (2)
-
Christian Grün -
Kendall Shaw