On Jul 17, 5:07 pm, Matt Sanford wrote:
> Short Answer: It's working as designed for security reasons. We
> don't like it any more than you do.
Thank you for your answer. There are pros and cons for both
approaches, and you had to make a decision.
Björn
>From a security standpoint, I'd hope the information is stored pre-
escaped, and that's why the API returns it that way. I'd like to offer
a +1 to liking the idea that the data I get from the API is escaped
for me.
On Jul 17, 11:27 am, Jeff Dairiki wrote:
> On Fri, Jul 17, 2009 at 07:53:27AM -0
On Fri, Jul 17, 2009 at 07:53:27AM -0700, Bjoern wrote:
>
> look for example at this: http://twitter.com/statuses/show/2689100482.json
>
> My status update was "test html escaping by twitter bold" but
> Twitter sends me "test html escaping by twitter bold<\/
> b>"
>
> So it has transformed t
Hi Bjoern,
Short Answer: It's working as designed for security reasons. We
don't like it any more than you do.
Long Answer: This has come up on the list quite a bit in the
past. Like a great many things spammers, scammers and unkind people
are the reason we can't have nice things
By now I have also create a a ticket for this:
http://code.google.com/p/twitter-api/issues/detail?id=845
My apologies for writing both at the issue tracker and in the forum. I
did not plan to create an issue at first, because I thought it
unlikely that it would be fixed. When I thought about addi
(somehow got the response above as email, too - sorry for replying
twice...)
Hi,
look for example at this: http://twitter.com/statuses/show/2689100482.json
My status update was "test html escaping by twitter bold" but
Twitter sends me "test html escaping by twitter bold<\/
b>"
So it has tra
On Fri, Jul 17, 2009 at 04:15:52AM -0700, Bjoern wrote:
>
> probably it is too late to change it now, but someone has to say it: I
> think it is the wrong approach to do HTML escaping in the API on the
> Twitter side.
What data are you referring to that is being HTML-escaped?
>From what I can t
Just had an idea: maybe Twitter could add an optional parameter to
switch off HTML escaping (&escapeHTHML=false or something like that).
That way developers who are unaware of the issue would get the escaped
HTML, and the developers who are aware could get the proper data.
