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.
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.
everyone. I am making a website with t-shirts. I dynamically generate preview cards for products using a JSON file but I also need to generate content for an HTML file when clicking on the card. So, when I click on it, a new HTML page opens like product.html?product_id=id. I do not understand how to check for id or this part ?prodcut_id=id, and based on id it generates content for the page. Can anyone please link some guides or good solutions, I don't understand anything :(.
It sounds like you want the user's browser to ask the server to load a particular page based on the value of a variable called product_id.
The way a browser talks to a server is an HTTP Request, about which you can learn all the basics on javascipt.info and/or MDN.
The ?product_id=id is called the 'query' part of the URL, about which you can learn more on MDN and Wikipedia.
A request that gets a page with this kind of URL from the server is usually a GET request, which is simpler and requires less security than the more common and versatile POST request type.
You may notice some of the resources talking about AJAX requests (which are used to update part of the current page without reloading the whole thing), but you won't need to worry about this since you're just trying to have the browser navigate to a new page.
Your server needs to have some code to handle any such requests, basically saying:
"If anybody sends an HTTP GET request here, look at the value of the product_id variable and compare it to my available HTML files. If there's a match, send a response with the matching file, and if there's no match, send a page that says 'Error 404'."
That's the quick overview anyway. The resources will tell you much more about the details.
There are some solutions, how you can get the parameters from the url:
Get ID from URL with jQuery
It would also makes sense to understand what is a REST Api and how to build a own one, because i think you dont have a backend at the moment.
Here some refs:
https://www.conceptatech.com/blog/difference-front-end-back-end-development
https://www.tutorialspoint.com/nodejs/nodejs_restful_api.htm
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.
When a visitor visits http://www.yourwebpage.com/
Is there a way to have the browser use the previously cached response? Or will it always make a request to the server?
I am guessing a request to the server will occur, but is then possible to respond with an empty string, and let the browser automatically use the cached response for index.html? Or do you always have to supply the entire answer?
The question is related to how much the initial index.html response for a JS based application should contain or if the index.html response should make a second request for html pieces and such.
// Example: Pseudo code
<html> ...
<script>
if ( !localStorage.index ) {
localStorage.index = loadFromServer( 'head.html' )
}
document.head.append(localStorage.index);
</script>
...</html>
The question boils down to, if i have ten templates.html files, which I would like to serve once, should they be included in the index.html response or should another request be made to fetch these as one bundle.
Obviously, if I make a second request, the browser will cache that response if proper headers are set, but that would cost another request, at least the first time.
If I include them in the index.html then the initial response will be bigger, but less than the two requests otherwise necessary, but how will subsequent requests to fetch the index.html be treated?
I have never visited a page who do not load something, although teoretically if the proper cached-headers from previous request has been set properly, it should be possible to treat it as an offline application, or is cache now applicable for initial requests? Only for requests made for instance by ajax or
Is the last statement true?
Basically, could you execute JavaScript by visiting a webpage using only cached data, that is without actually needing to make any request, or at least wait for an answer.
Is this possible? Perhaps storing the entire index.html in the localStorage is one way and have the index.html response the second time respond with only a script tag saying load from localStorage.
EDIT 1
I have come to understand that there is something called a Manifest for at least Firefox which can allow for the treatment as such as an application install the first time. https://developer.mozilla.org/en-US/Apps/Build/Manifest
Yes, your web server (and/or web app framework) should use cache headers to give this sort of instruction to the browser. Cache headers include etags and cache-control. A full example and explanation is here: https://www.mnot.net/cache_docs/#CACHE-CONTROL
But basically, those tell the browser when to consider the fetched content stale, when to actually make a request. Further, if the server knows the information hasn't been changed, it will respond with a HTTP 304 response, which will result in the client using the cached copy instead as well.
You really don't need to use the localstorage option unless you want your JS to definitely never ask the server for something unless it's not in localstorage. The problem with that is that you then have to manage your own cache invalidation, etc.
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.