(As a preface, SurveyMonkey requests that questions to their developers be posted to SO with the tag 'surveymonkey')
We've been calling the SurveyMonkey API without problem until yesterday. As of yesterday, the response we're getting back seems to contain an invalid JSON string. The problem seems to lie in the response object containing several unescaped double-quote characters. Below is an example of the response we're getting when calling get_survey_details:
"heading": "Please click "Next" below to proceed.\r\n"
As you can see, there are two unescaped double-quotes ("Next"), which is resulting in an invalid JSON object error.
To verify that it isn't a problem with our code, I made the same API call via terminal (curl), and got the same response.
Reproducing the issue is as easy as creating a survey with double-quotes in a heading, question text, or answer text, and then calling get_survey_details.
Seeing as this has been working fine up until yesterday, I'm wondering if something has recently changed on the SurveyMonkey end of things? We're dead in the water until this gets resolved.
Thanks!
Per the developers, this was an issue on their end. As of yesterday, they had pushed a fix which resolves this issue.
Related
After adding faq schema to my blog.
There was a notification from Google search console saying "unparsable structured data" with this link
"https://www.chikasom.com/2020/12/nigerian-defence-academy-kaduna-list.html?m=1"
and that the faq schema implemented on the Blogger site is yet to be indexed.
Even shema validation website and Google rich test result proves that there is an error.
I am not sure but I feel the problem may be from these characters "”" and I tried removing them but I couldn't.
{
"#context”:
I didn't see any result since I was unable to remove the characters "”" and I am not sure whether it's the problem
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
My company sends out various newsletters (all double opt-in and CAN-SPAM compliant of course) and we're having an issue with Apple devices. All of the links in the emails become corrupted in nearly the same way, but all other code/content remains untouched. Here is some key information:
So far we've only seen this on Apple products (iPads, iPhones)
Not every user on the same device has the issue (Our two company iPads don't get it, but users with iPads have reported it, so it may have to do with the iOS version)
For users which the issue it affects, it doesn't affect every newsletter they receive. Also, either all the links work or all the links are corrupted; never a mix.
The newsletters are built automatically by pulling articles from our various websites and inserting them into a template
The issue happens regardless of the email service/client being used. Eg: from an iPad using a gmail account via the gmail app or via gmail.com in a browser.
If the user accesses the same email using a non Apple products, the links are not corrupted.
If the user forwards the corrupted email to someone who accesses it via a non Apple device, the corruption remains.
Here is a sample of how the URL changes:
correct:
http://www.example.com/path/link.php?M=5009308&N=21109&L=34170&F=H
corrupted:
http://www.example.com/path/link.php?MQ80105&N!109&L4170&F=H
correct:
http://www.example.com/path/link.php?M=5009308&N=21109&L=34087&F=H
corrupted:
http://www.example.com/path/link.php?MQ80105&N!109&L4087&F=H
correct:
http://www.example.com/path/link.php?M=5009308&N=21109&L=34137&F=H
corrupted:
http://www.example.com/path/link.php?MQ80105&N!109&L4137&F=H
All of the links on all newsletters follow the exact same pattern. The only difference between newsletters and links would be the numbers for the query variables (M, N, and L).
It only affects the query part of the URL
It seems to center around the "=" sign on each URL when it's followed by a number:
"=5009308" became "Q80105"
"=21109" became "!109"
"=34137" became "4137"
Part of it seems like it's a character encoding issue but you'd think it would affect more than just the query part of links (ie, you'd see text in other parts of the HTML/content changed also).
Does anyone have any idea what could be causing this extremely strange bug? Any help or ideas would be greatly appreciated!
At least part of it is caused by something between your mail server and their device deciding that you're using quoted printable encoding and "fixing" it. That would account for =21 being replaced by ! and for =34 being replaced by 4. I don't know what triggers this but based on your description I would suspect that something in your outgoing email headers is telling the device it needs to do this. If your URLs always contain = but are only corrupted some of the time, your headers may be inconsistent. If the URLs only contain = some of the time and are corrupted every time they do, then the issue is always there but only visible with the right data.
Try your original URLs at the online quoted printable decoder, you'll get exactly the same changes.
I am using the following API call to pull all of the videos with <TAG> from <CHANNEL>:
http://gdata.youtube.com/feeds/api/users/<CHANNEL>/uploads/-/<TAG>/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
But for some tag names the results are wrong, or even empty. For example
http://gdata.youtube.com/feeds/api/users/NintendoFR/uploads/-/n3ds/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
only has 1 result, but I know that there are at least 20 videos with the tag "n3ds", on the other hand
http://gdata.youtube.com/feeds/api/users/NintendoFR/uploads/-/wiiu/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
gives the expected 36 results. Any ideas? Or anyone with similar problems?
Have the same problem (search by tag no longer works).
The Youtube API team has history for making un-announced changes.
For example, a few month's back, the "video description" field was truncated
- without any announcement of the change
- without updating the doco to reflect the change
This looks like a similar change, i.e. tag search has been depreciated (switched off).
Workaround (for your videos) is to include the tag(s) in the first 150 chars or so of the video's description.
We have a similar problem. A few days or weeks ago, a piece of code that sends these requests stopped delivering results. After a bit of research, we found out that getting results is random:
On some occasions we get the right results
On some occasions we get no results.
The only difference we could find in both requests is that a parameter is missing from the requests. When requesting an answer in XML, in the feed node an item is missing:
<feed xmlns:media='http://search.yahoo.com/mrss/'></feed>
Although we do not know why this is, at least now you know that you are not the only one that has this problem.
We are building an app that accesses the Twitter search over JSONP.
It mostly works fine, but occasionally the request returns a JSONP callback that consists of weird unparseable characters.
Here is an example: http://search.twitter.com/search.json?result_type=recent&rpp=100&geocode=51.4375857,-0.1658648,1km&page=5&callback=jsonp1272532482854
(If you change page=5 to a value less than 5 in the URL it works fine)
So
Am I doing something wrong?
Can anyone suggest a workaround?
Edit: This is no longer a problem, so I guess this was just a bug that got fixed.
This is a bug that should be fixed now. https://groups.google.com/d/topic/twitter-development-talk/X7J_e9bOY-o/discussion
I'm trying to use OAuth with Twitter, and I have my head wrapped around the pieces that need to be put in place to get a request token. But, it's not working. And the error message that I'm getting back isn't terribly helpful.
Luckily I found a tester but again, the error message there isn't terribly helpful. "Invalid signature." Ok, great. But since there are several steps involved (truth be told, all of which confuse the hell out of me) in generating the signature, I'm at a loss.
Is there another tool out there that might be more helpful? Maybe one where I can see what the data should be at each step (check that the request concatenation is right, check that the initial signing is right - i'm using HMAC-SHA1, check that the base 64 is right, etc).
Yes. Run, do not walk, to Hueniverse - one of the neatest pieces of Javascript you'll see!