You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Patrick Moriarty <pm...@annadaletech.com> on 2009/01/23 11:19:34 UTC
T5: application/json response and GZip compression
Hi,
Since the recent introduction of gzip compression returning a
JSONObject from a mixin event method results in an empty responseText
in Firefox. It seems there is some problem with Content-Type:
application/json and Content-Encoding: gzip headers that prevents the
response from being decompressed correctly by the browser. Has anyone
come across this before? A Google search doesn't reveal much.
For now I'm disabling compression for "application/json". Perhaps
this should be the default behaviour?
This seems to be the case with IE too. I attempted to check behaviour
in Opera, but the response was not gzipped since the Accept-Encoding
request header sent by Opera includes a space (eg. "deflate, gzip,
..." instead of "deflate,gzip,...").
IE6 also includes a space but places gzip at the beginning. Tapestry
should probably trim the spce before comparing to "gzip" in
ResponseCompressionAnalyzerImpl.
Thanks,
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: application/json response and GZip compression
Posted by Patrick Moriarty <pm...@annadaletech.com>.
See TAP5-467, TAP5-468, TAP5-469.
2009/1/26 Patrick Moriarty <pm...@annadaletech.com>
> My pleasure, most of the time ;)
>
> I'll create a couple of JIRA issues for these.
>
> Patrick
>
> 2009/1/23 Howard Lewis Ship <hl...@gmail.com>
>
>> These all sound like issues that should be added to JIRA. Thanks for
>> hanging out on the bleeding edge!
>>
>> On Fri, Jan 23, 2009 at 3:38 AM, Patrick Moriarty
>> <pm...@annadaletech.com> wrote:
>> > I've resorted to returning a TextStreamResponse with
>> > "application/json" as the content type in order to bypass gzip
>> > compression.
>> >
>> > 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
>> >> Looks like adding "application/json" to the configuration for
>> >> ResponseCompressionAnalyzer doesn't quite do it because it's compared
>> >> directly against "application/json;charset=UTF-8".
>> >>
>> >> I could add "application/json;charset=UTF-8" but I think
>> >> ResponseCompressionAnalyzer should probably ignore the charset and any
>> >> other parameters in isCompressable()
>> >>
>> >> Patrick
>> >>
>> >>
>> >> 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
>> >>> Hi,
>> >>>
>> >>> Since the recent introduction of gzip compression returning a
>> >>> JSONObject from a mixin event method results in an empty responseText
>> >>> in Firefox. It seems there is some problem with Content-Type:
>> >>> application/json and Content-Encoding: gzip headers that prevents the
>> >>> response from being decompressed correctly by the browser. Has anyone
>> >>> come across this before? A Google search doesn't reveal much.
>> >>>
>> >>> For now I'm disabling compression for "application/json". Perhaps
>> >>> this should be the default behaviour?
>> >>>
>> >>> This seems to be the case with IE too. I attempted to check behaviour
>> >>> in Opera, but the response was not gzipped since the Accept-Encoding
>> >>> request header sent by Opera includes a space (eg. "deflate, gzip,
>> >>> ..." instead of "deflate,gzip,...").
>> >>> IE6 also includes a space but places gzip at the beginning. Tapestry
>> >>> should probably trim the spce before comparing to "gzip" in
>> >>> ResponseCompressionAnalyzerImpl.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Patrick
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
Re: T5: application/json response and GZip compression
Posted by Patrick Moriarty <pm...@annadaletech.com>.
My pleasure, most of the time ;)
I'll create a couple of JIRA issues for these.
Patrick
2009/1/23 Howard Lewis Ship <hl...@gmail.com>
> These all sound like issues that should be added to JIRA. Thanks for
> hanging out on the bleeding edge!
>
> On Fri, Jan 23, 2009 at 3:38 AM, Patrick Moriarty
> <pm...@annadaletech.com> wrote:
> > I've resorted to returning a TextStreamResponse with
> > "application/json" as the content type in order to bypass gzip
> > compression.
> >
> > 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
> >> Looks like adding "application/json" to the configuration for
> >> ResponseCompressionAnalyzer doesn't quite do it because it's compared
> >> directly against "application/json;charset=UTF-8".
> >>
> >> I could add "application/json;charset=UTF-8" but I think
> >> ResponseCompressionAnalyzer should probably ignore the charset and any
> >> other parameters in isCompressable()
> >>
> >> Patrick
> >>
> >>
> >> 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
> >>> Hi,
> >>>
> >>> Since the recent introduction of gzip compression returning a
> >>> JSONObject from a mixin event method results in an empty responseText
> >>> in Firefox. It seems there is some problem with Content-Type:
> >>> application/json and Content-Encoding: gzip headers that prevents the
> >>> response from being decompressed correctly by the browser. Has anyone
> >>> come across this before? A Google search doesn't reveal much.
> >>>
> >>> For now I'm disabling compression for "application/json". Perhaps
> >>> this should be the default behaviour?
> >>>
> >>> This seems to be the case with IE too. I attempted to check behaviour
> >>> in Opera, but the response was not gzipped since the Accept-Encoding
> >>> request header sent by Opera includes a space (eg. "deflate, gzip,
> >>> ..." instead of "deflate,gzip,...").
> >>> IE6 also includes a space but places gzip at the beginning. Tapestry
> >>> should probably trim the spce before comparing to "gzip" in
> >>> ResponseCompressionAnalyzerImpl.
> >>>
> >>> Thanks,
> >>>
> >>> Patrick
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: application/json response and GZip compression
Posted by Howard Lewis Ship <hl...@gmail.com>.
These all sound like issues that should be added to JIRA. Thanks for
hanging out on the bleeding edge!
On Fri, Jan 23, 2009 at 3:38 AM, Patrick Moriarty
<pm...@annadaletech.com> wrote:
> I've resorted to returning a TextStreamResponse with
> "application/json" as the content type in order to bypass gzip
> compression.
>
> 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
>> Looks like adding "application/json" to the configuration for
>> ResponseCompressionAnalyzer doesn't quite do it because it's compared
>> directly against "application/json;charset=UTF-8".
>>
>> I could add "application/json;charset=UTF-8" but I think
>> ResponseCompressionAnalyzer should probably ignore the charset and any
>> other parameters in isCompressable()
>>
>> Patrick
>>
>>
>> 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
>>> Hi,
>>>
>>> Since the recent introduction of gzip compression returning a
>>> JSONObject from a mixin event method results in an empty responseText
>>> in Firefox. It seems there is some problem with Content-Type:
>>> application/json and Content-Encoding: gzip headers that prevents the
>>> response from being decompressed correctly by the browser. Has anyone
>>> come across this before? A Google search doesn't reveal much.
>>>
>>> For now I'm disabling compression for "application/json". Perhaps
>>> this should be the default behaviour?
>>>
>>> This seems to be the case with IE too. I attempted to check behaviour
>>> in Opera, but the response was not gzipped since the Accept-Encoding
>>> request header sent by Opera includes a space (eg. "deflate, gzip,
>>> ..." instead of "deflate,gzip,...").
>>> IE6 also includes a space but places gzip at the beginning. Tapestry
>>> should probably trim the spce before comparing to "gzip" in
>>> ResponseCompressionAnalyzerImpl.
>>>
>>> Thanks,
>>>
>>> Patrick
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: application/json response and GZip compression
Posted by Patrick Moriarty <pm...@annadaletech.com>.
I've resorted to returning a TextStreamResponse with
"application/json" as the content type in order to bypass gzip
compression.
2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
> Looks like adding "application/json" to the configuration for
> ResponseCompressionAnalyzer doesn't quite do it because it's compared
> directly against "application/json;charset=UTF-8".
>
> I could add "application/json;charset=UTF-8" but I think
> ResponseCompressionAnalyzer should probably ignore the charset and any
> other parameters in isCompressable()
>
> Patrick
>
>
> 2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
>> Hi,
>>
>> Since the recent introduction of gzip compression returning a
>> JSONObject from a mixin event method results in an empty responseText
>> in Firefox. It seems there is some problem with Content-Type:
>> application/json and Content-Encoding: gzip headers that prevents the
>> response from being decompressed correctly by the browser. Has anyone
>> come across this before? A Google search doesn't reveal much.
>>
>> For now I'm disabling compression for "application/json". Perhaps
>> this should be the default behaviour?
>>
>> This seems to be the case with IE too. I attempted to check behaviour
>> in Opera, but the response was not gzipped since the Accept-Encoding
>> request header sent by Opera includes a space (eg. "deflate, gzip,
>> ..." instead of "deflate,gzip,...").
>> IE6 also includes a space but places gzip at the beginning. Tapestry
>> should probably trim the spce before comparing to "gzip" in
>> ResponseCompressionAnalyzerImpl.
>>
>> Thanks,
>>
>> Patrick
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: application/json response and GZip compression
Posted by Patrick Moriarty <pm...@annadaletech.com>.
Looks like adding "application/json" to the configuration for
ResponseCompressionAnalyzer doesn't quite do it because it's compared
directly against "application/json;charset=UTF-8".
I could add "application/json;charset=UTF-8" but I think
ResponseCompressionAnalyzer should probably ignore the charset and any
other parameters in isCompressable()
Patrick
2009/1/23 Patrick Moriarty <pm...@annadaletech.com>:
> Hi,
>
> Since the recent introduction of gzip compression returning a
> JSONObject from a mixin event method results in an empty responseText
> in Firefox. It seems there is some problem with Content-Type:
> application/json and Content-Encoding: gzip headers that prevents the
> response from being decompressed correctly by the browser. Has anyone
> come across this before? A Google search doesn't reveal much.
>
> For now I'm disabling compression for "application/json". Perhaps
> this should be the default behaviour?
>
> This seems to be the case with IE too. I attempted to check behaviour
> in Opera, but the response was not gzipped since the Accept-Encoding
> request header sent by Opera includes a space (eg. "deflate, gzip,
> ..." instead of "deflate,gzip,...").
> IE6 also includes a space but places gzip at the beginning. Tapestry
> should probably trim the spce before comparing to "gzip" in
> ResponseCompressionAnalyzerImpl.
>
> Thanks,
>
> Patrick
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org