You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Gagandeep singh <ga...@gmail.com> on 2010/09/01 03:34:21 UTC

Re: Removing charset information from meta http-equiv content type (issue1841045)

Tested by putting the following content-type response header in a gbk
encoded website and removing the charset information from Content-Type meta
http-equiv tag in firefox:

Response header:
Content-Type: text/html; charsett=gb2312

Firefox does not render the page correctly (but renders it correct if i
spell it as charset=gb2312) , which means that it ignores the misspelt
'charsettt' attribute. So i think ignoring it for now as we are doing is the
right thing to do.
Please commit if you approve of the change.

Thanks
Gagan


2010/8/31 ๏̯͡๏ Jasvir Nagra <ja...@google.com>

>
>
> On Tue, Aug 31, 2010 at 9:06 AM, Ziv Horesh <zh...@gmail.com> wrote:
>
>> On Thu, Aug 26, 2010 at 7:27 PM, <ga...@gmail.com> wrote:
>>
>> >
>> > http://codereview.appspot.com/1841045/diff/34001/24002
>> > File
>> >
>> >
>> java/gadgets/src/test/java/org/apache/shindig/gadgets/rewrite/ContentTypeCharsetRemoverRewriterTest.java
>> > (right):
>> >
>> > http://codereview.appspot.com/1841045/diff/34001/24002#newcode114
>> >
>> >
>> java/gadgets/src/test/java/org/apache/shindig/gadgets/rewrite/ContentTypeCharsetRemoverRewriterTest.java:114:
>> > + "<META Content=\"text/html ; charsett=\'hello\'; hello=world\" "
>> > On 2010/08/26 22:29:45, zhoresh wrote:
>> >
>> >> I don't think this should be recognized as charset, it should not be
>> >>
>> > removed.
>> >
>> > I thought we should retain such attributes because most likely the user
>> > meant charset.
>> > Removing for now. Lets take care of it when we find such an issue.
>>
>>
>> In the case of accel you probably want to treat bad input the same as a
>> browser does.
>> Maybe you can verify what browser does for such case and correct shindig
>> if
>> needed.
>>
>
> There isn't just one browser behavior.  If you go down this path, please
> aim for the behavior that is the intersection of the Grade A<http://developer.yahoo.com/yui/articles/gbs/#gbschart>browsers - ie. feel free to accept bad input, but output something that is
> consistently interpreted on all popular browsers.
>
>
>> >
>> >
>> > http://codereview.appspot.com/1841045/
>> >
>>
>
>

Re: Removing charset information from meta http-equiv content type (issue1841045)

Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
LGTM

On Tue, Aug 31, 2010 at 6:34 PM, Gagandeep singh <ga...@gmail.com>wrote:

> Tested by putting the following content-type response header in a gbk
> encoded website and removing the charset information from Content-Type meta
> http-equiv tag in firefox:
>
> Response header:
> Content-Type: text/html; charsett=gb2312
>
> Firefox does not render the page correctly (but renders it correct if i
> spell it as charset=gb2312) , which means that it ignores the misspelt
> 'charsettt' attribute. So i think ignoring it for now as we are doing is the
> right thing to do.
> Please commit if you approve of the change.
>
> Thanks
> Gagan
>
>
> 2010/8/31 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
>
>
>>
>> On Tue, Aug 31, 2010 at 9:06 AM, Ziv Horesh <zh...@gmail.com> wrote:
>>
>>> On Thu, Aug 26, 2010 at 7:27 PM, <ga...@gmail.com> wrote:
>>>
>>> >
>>> > http://codereview.appspot.com/1841045/diff/34001/24002
>>> > File
>>> >
>>> >
>>> java/gadgets/src/test/java/org/apache/shindig/gadgets/rewrite/ContentTypeCharsetRemoverRewriterTest.java
>>> > (right):
>>> >
>>> > http://codereview.appspot.com/1841045/diff/34001/24002#newcode114
>>> >
>>> >
>>> java/gadgets/src/test/java/org/apache/shindig/gadgets/rewrite/ContentTypeCharsetRemoverRewriterTest.java:114:
>>> > + "<META Content=\"text/html ; charsett=\'hello\'; hello=world\" "
>>> > On 2010/08/26 22:29:45, zhoresh wrote:
>>> >
>>> >> I don't think this should be recognized as charset, it should not be
>>> >>
>>> > removed.
>>> >
>>> > I thought we should retain such attributes because most likely the user
>>> > meant charset.
>>> > Removing for now. Lets take care of it when we find such an issue.
>>>
>>>
>>> In the case of accel you probably want to treat bad input the same as a
>>> browser does.
>>> Maybe you can verify what browser does for such case and correct shindig
>>> if
>>> needed.
>>>
>>
>> There isn't just one browser behavior.  If you go down this path, please
>> aim for the behavior that is the intersection of the Grade A<http://developer.yahoo.com/yui/articles/gbs/#gbschart>browsers - ie. feel free to accept bad input, but output something that is
>> consistently interpreted on all popular browsers.
>>
>>
>>> >
>>> >
>>> > http://codereview.appspot.com/1841045/
>>> >
>>>
>>
>>
>