I am displaying a Twitter feed from their feed widget on my website. Sometimes the widget likes to not display any information. I figure this is because the API is overloaded. Regardless, is there any known way to display an error message in the event that Twitter can't load my feed? Has anybody else experienced these issues?
Firstly use a suitable http recording proxy for your OS (Fiddler2 is fantastic if you are on windows), shift F5 the page until you get the fault.
Filter the log for hosts widgets.twimg.com or api.twitter.com... This diagnoses the failure point because:
If the js (or css) request to widgets.twimg.com fails (Look for a 404 or truncated text), then the javascript failed to fetch. Unlikely since files should be static.
If the api.twitter.com request is missing, then the javascript failed to run.
If the api.twitter.com request occurs, but there is a failure in the response (bad response code or response looks whack) then the twitter api is failing to give you the feed.
For detecting 1 in javascript, you can detect the failure to load by using a timeout, and onload check that it loaded (simple check is that window.twttr exists - however not a great test because that gets set at top of javascript, so only confirms that javascript syntax was valid and started running). (Might need onreadystate to detect load for IE?)
<script src="http://widgets.twimg.com/j/2/widget.js" onload="twitterloaded()"></script>
For detecting 2, run page with debugger.
For 3, from a quick look at the code, looks like the code retries requests to the twitter api (you might want to look ath the configuration settings for the api) and it looks like there are api variables to check if everything is running e.g. TWTR.Widget.isLoaded _isRunning and _hasOfficiallyStarted.
Related
I'm writing a sever application in go providing a Rest-API. If the server gets a GET without JSON-content-type header it serves an empty html-page having a javascript module in its head. This javascript code uses fetch to consume the Rest-API and populates then according the document.body with content fetched from the server. Each "link" in the content triggers further calls to the API and corresponding updates to the content.
So far so good. But I made two irritating observations.
(obviously) the "back" and "forward" buttons of the browser stay inactive. Which seems logical since there are no loaded URLs associated with the content changes.
If I come to my Rest-UI from an other page and hit the browser's back-button I get as expected the other page back but if I hit now the browser's forward-button I see the JSON-response from my initial fetch instead of my Rest-UI content. Reloading my page makes it all good again but I can't offer that behavior to any user :)
Are there common approaches to deal with this behavior? E.g. removing the browser controls completely, feeding the browser-history "by hand" with js-callbacks, caching directives, ... (I'm inexperienced with js)
The root of the problem is that I overloaded the response of a GET request on the server-side: if the GET-request accepts JSON the server returns JSON otherwise it returns a html-page with the javascript which consumes the JSON. I. e. the javascript fetch for the JSON is the last GET-response for a given URL and goes as such into the browser's cache associated with that URL. A solution to that problem which works for me is to send a header with the JSON response turning of caching and signalling the browser with the "Vary"-header that the response depends on the "Accept"-header. An other solution might be to add distinct endpoints to the server for the Rest-requests.
I am attempting to make a request to the SoundCloud API. Then when I get the response I set the stream_url as the source of an < audio > element.
This works:
http://matthiasdv.org/beta/
But not always... When you search for 'Bonobo' for example, you can play the first few tracks without any issue. But when you try to play 'London Grammar - Hey Now (Bonobo remix)' - the 7th result - it won't play. It throws no errors whatsoever.
I've been tinkering around with Chrome's webdev-tools and under the network tab I see the requests being made. I found that tracks that DO play have a short Request Url, like this:
https://ec-media.sndcdn.com/vR5ukuOzyLbw.128.mp3?f10880d39085a94a0418a7ef69b03d522cd6dfee9399eeb9a522029f6bfab939b9ae57af14bba24e44e1542924c205ad28a52352010cd0e7dd461e9243ab54dc0f0bba897d
And the ones that don't look like this:
https://cf-media.sndcdn.com/8PCswwlkswOd.128.mp3?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiKjovL2NmLW1lZGlhLnNuZGNkbi5jb20vOFBDc3d3bGtzd09kLjEyOC5tcDMiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MzM0Mjc2MDN9fX1dfQ__&Signature=cD-XVhnvQnIATkfrBDDVy0Q7996C8DymwxRLwBBduab0~L0MynF1ftcMky~21T8Q-gCZ2~dMK8dz7uVxvJTIJgXPxEZvhNtbvescMK6iFMg-xSAty-4OhJYjrIZJ2j8NE4uNA4Ml7MWbWcQw4KtUtpZitOQuguS3DPFDII3VF-dvzb2L~xG-G8Uu3uOnI1WhnAAfhf1QWMO7swwB89HtcCiuVBmfluG28ELrJEq-au8mqIMB3sLTno6nUuTtpHXR2ayXBsYcYLLJVXa3Ul8p1rhLS5XWHKWXY8xug4jwey27~C5PVAomK6Z5lJx-mz-0zYs4riUYtl0zACbZ1OfwTQ__&Key-Pair-Id=APKAJAGZ7VMH2PFPW6UQ
Now at first glance I figured it was an encoding issue, but wrapping a quick encodeURI() around the ajax url did not work.
Furthermore I do not understand where these urls come from. In my code I am directing my ajax request towards, for example:
https://api.soundcloud.com/tracks/140326936/stream?client_id=5c6ceaa17461a1c79d503b345a26a54e
Thus, the request url in the GET request (as found under 'network' in Chrome's webdev tools) makes no sense to me. Is SoundCloud redirecting get requests to a CDN-host? One more thing I've noticed is that each time TWO requests are fired instead of one. The first one is always canceled and contains a 'Provisional headers are shown' warning. I believe this is because I am setting crossOrigin = "anonymous", otherwise certain browsers would not load the content.
What I guess may cause the problem is that when the url is set as the src attribute of the element an evenListener is fired in the dancer.js library, which handles the Audio Api and the playback (https://github.com/jsantell/dancer.js/). It may be that encodeURI() is required somewhere in the library.
I decided to ask the question anyhow because I don't understand how the Request Urls's above are formed and why two, instead of one, requests are being fired and why the first is always cancelled.
Any hints which my solve the playback issue are more than welcome too...
When you run the request for
https://api.soundcloud.com/tracks/140326936/stream?client_id=5c6ceaa17461a1c79d503b345a26a54e
you get a HTTP 302 Found response from the server, which is a URL redirect (http://en.wikipedia.org/wiki/HTTP_302). This will cause your browser to load from the new URL that the server returns, and thus the two requests you see. The server basically says "yeah, I know where to find that file, ask that guy over there".
The reason why one works and the other not, I'd think, is that https://ec-media.sndcdn.com has the Access-Control headers set while https://cf-media.sndcdn.com doesn't. This is an issue with the server configuration and unfortunately nothing you can control from the client side. Dunno if it's a deliberate move by soundcloud or if it's something you could ask them about.
I have been introduced to a web application that I need to make some modifications to.
The app is huge, and there are perhaps 100 Javascript files. These files send requests to a third party API all the time.
Now, in the console, I can see all these requests. Let's say that one looks like:
GET http://123.456.789.10:8000/v1/accounts/accountnum/children?_=1422026843600
Then of course I can see the parameters sent, headers and response. My problem is that I need to locate the JS file which is sending one particular request. Searching all the files for the API target URL reveals that 40 or 50 files send requests to this same URL, with similar parameters.
Is there a way I can find out the source file of one specific request? Something like sent from filename.js on line 123 would be ideal, but just the file name would be of great help too.
I could go through all the files and try each one individually, but that seems like a huge waste of time. There would be A LOT of code to go through.
If you know what to do in the application to make the request occur, in Chrome you can use an XHR breakpoint to catch it:
Navigate to the point where you're about to do the thing that causes the request
Open Dev Tools
Switch to the Sources tab
On the right, scroll down to "XHR Breakpoints"
Click the + button, fill in some appropriate subset of the URL (or leave it blank to break on all XHR)
Add it
Do the thing that does the request
Chrome will break and take you to the line of code that was triggering the XHR.
I am doing a jquery.ajax() call on one of our pages to fetch a small text file. I see some of the requests (not all) fail with resp.statusText: "No Transport" and resp.status : 0
What does the error mean (No Transport with a resp code of 0). Strangely it works on some browsers, and doesn't work on some. I couldn't find a patter by looking at the user agents of browsers, where it failed.
Any help would be highly appreciated. I am a beginner to javascript and jquery library, let me know if I omitted crucial information.
My use case:
abc.mydomain.com contains jquery.ajax(url:xyz.mydomain.com) call
Most likely it prevents you from firing a request because it things you are trying to access another domain. xyz.mydomain.com !== mydomain.com.
Why that is not allowed?
Read
Use a Web Proxy for Cross-Domain XMLHttpRequest Calls
Why the cross-domain Ajax is a security concern?
An example to why this is a security issue, assume you installed a bad plugin to your browser. If that plugin got the permission, it can read all loaded files to your browser and be able to edit/change/inject content and codes. Then it might send all collected data to designer own server.
... The most common business needs that are easily accomplished with browser plug-ins are: modify default search, add side frames, inject new content into existing webpage ...more
A good practice is to fetch the data thru ajax via JSON, if you are trying to access another site beside the one the script is calling from, then use JSON-P.
Read
JSON-P
JSON-P call to subdomain
Chrome ajax call to subdomain
A common architecture is to call the current domain that the script is loaded from, then use server script to fetch data from the other domain where the other domain will response to the request and return the data.
A code snippets of your function will help us understand your issue more.
I'm trying to make auto-reload counter (for ex.: Messages [num]).
So, I just in setTimeout(); getting JSON code from test_ajax.php. I think it's not correctly..
Can I send info by server (I think not, but suddenly I something don't know..)?
Why I think that's not correctly: because when I'm looking in my chrome network log (F12 -> network tab), I see a lot of requests (to test_ajax.php), but when, I'm visiting vk.com (great example for ajax) or facebook.com, I don't see any requests while something will not change.
So, what's incorrectly in my solution (or what's bad..)?
UPD: Sorry, vk.com sending requests to q%NUM%.queue.vk.com every 25s, but until 25s last request's status is "Pending". When someone, for example, sending me a message it immediately display it. And request has parameter "wait" which equals 25. This delay in requests doing on server side.. But how?
Ajax counter can be done in easy just include below files
index.html
counter.php (ajax file)
necessary images
JS file (for jquery paging call)
download link: https://docs.google.com/open?id=0B5dn0M5-kgfDcE0tOVBPMkg2bHc
What you are looking for is called COMET (also sometimes called Reverse AJAX) techniques.
Doing what you want to do, e.g. regular polls, is one way of doing it.
A lot is actually happening on the server side; to avoid recreating new connections on every poll, some servlet containers like Jetty started to implement techniques like Continuation which basically maintain a two-way connection open.
In the Java world, with Servlet 3, you have asynchronous calls as part of the specs.