Saving all browser's (any) AJAX activity to disk - ajax

I'm developing web application that uses AJAX a lot. It sends several AJAX requests to server per second and update page's content based on the request result.
Is there a way I can save all responses sent from server to browser using AJAX to disc in order to analyze it later?
It is not good to make 'alert' after each request because there are too many requests and I'll not be able to see if the browser works well in this case.
I've tried to use firebug or greasemonkey for Firefox but I failed to save data to disk using them.
Is there any solution for it? Thanks for your help.

Have you tried Fiddler?
It's an application which monitors all http traffic. It's good, and it's free.

Related

How to approach creating a Spring Boot backend which follows requests like a browser to set cookies?

I'm trying to create a Spring Boot backend which is able to make requests to this url. When requesting this url with a fresh browser window, aprox. 50 requests are made.
I managed to saved the cookies from the first request to the above url, but how do I approach following the follow-up requests from the browser, which are often triggered by javascript code, to set all the cookies? Is there an easy way?
My approach is to request all the urls which set cookies manually using my network recording. Is there a better, automatic way? Thanks so much for your help.
You could make the request with Selenium in headless mode to achieve what you need with very little effort.

Is a HTTP GET the same thing as an AJAX call?

This is something I was wondering, but could not get a definitive answer elsewhere.
Is a http get request asynchronous?
If they're different, are there any major differences?
Not looking for opinions, just definitive answers.
Googling has just repeatedly led me to examples of one or the other.
HTTP is the most common protocol used to transfer data on the web. It's what the browser users on port 80 for all websites. Pages, AJAX, etc.
GET is a particular "verb" used in an HTTP request. A GET request is usually distinct in that it doesn't have a request body and it doesn't expect to modify anything on the server, simply "get" data.
AJAX requests are essentially HTTP requests made from JavaScript code, rather than from navigation in the browser. They may be GET requests, or they may be other kinds of HTTP requests. Structurally they're no different from any other HTTP request made by the browser, they're just made from code instead of the browser's UI.
There is overlap between these three terms, because they're not mutually exclusive versions of the same thing. They're apples and oranges, really. HTTP isn't different from the other two, it would be different from something like FTP. GET isn't different from the other two, it would be different from something like POST.
You can see a lot of this in action by taking a look at your browser's debugging tools. Visiting any reasonably active page (such as Stack Overflow, for example) will show you a number of requests being made and the server's responses to those requests. As you interact with a page which uses AJAX, watch those requests in the debugging tools and see how they're structured. Load a page or two by navigation and see how those requests are structured.
There's not much to it, really. It's all requests and responses, each of which is simply headers and content.
Ajax used so web applications can send data to and retrieve from a server asynchronously (in the background) without interfering with the display and behavior of the existing page.
HTTP GET or HTTP POST are method in the HTTP Protocol, which are a way to send and receive the data.
While Ajax is the Car, HTTP Protocol is the Driving laws.
Few examples of everyday surfing using Ajax:
Facebook Feed - When scrolling to the bottom of Facebook a Loader circle appears that loads a more prior updates on your wall, this is happening without surfing to another page, but rather retrieving it while still on the same page.
Google Omnibox Prediction - When typing part of the text in the Omnibox, google will suggest you the completion of your text while you're still typing.
First try to get through : GET vs POST.
An ajax call can be GET or POST or PUT or any other.
To differentiate between ajax GET & normal HTTP GET.
Ajax GET seems asynchronous by as the request is sent using another thread by the browser.
Ajax GET request has additional X-Requested-With: XMLHttpRequest.
GET Request is captured by browser history, whilw Ajax GET does not get captured.

BlazeMeter Chrome extension not recording call to fill table

I am currently working on making a JMeter test for my company's website. I've been using the BlazeMeter Chrome extension to record http requests because I haven't been able to get the certificate working for the JMeter 2.11 proxy server.
On one of the site's main pages there is a large table that is filled by what I believe is an AJAX call. I use the extension to record using the page and add the recorded http requests to my test. However, when I run the test with those requests, none of the requests get responses that are anywhere near long enough to fill the table.
I made sure that the BlazeMeter extension is not just recording high-level requests, and that the cache is disabled. I know that the data is not sent with the initial html page because I can see that the table element is initially empty. Does the BlazeMeter extension not record every request? Or am I wrong to assume that the table is filled by and AJAX call? Or is there another protocol I'm missing entirely?
I'd start by analyzing the actual HTTP requests themselves. At the end of the day ANY performance tool you use to record browser activity is only going to record and playback the requests.
Is there an actual request that you can see your browser making that is not being recorded by the BlazeMeter chrome plugin?

Google chrome requests multiple times for a page asp.net mvc 3

Google chrome is sending multiple requests for a page.
I'm using c# asp.net mvc 3 razer. when i tested with other browsers, it is only executing one time. i checked the requests with fiddler. so i noticed that chrome is sending 2 requests.
Any idea about how to prevent the additional requests?
Thanks.
Do you have a favicon? Chrome will send a request for favicon on every single request until it finds one.
server socket receives 2 http requests when I send from chrome and receives one when I send from firefox
Do you have any JavaScript on this page that make calls to the server?
If so, perhaps the events with the JavaScript are firing differently among the different browser which would explain why you see a double hit in some browsers but not others.
Do you have any chrome extension that might trigger the second request? I know that HTML validator extension for chrome occasionally does this. Try disabling all plugins extensions and see if the issue still occurs

GWT caching - a cookies approach

I'am trying to improve the performance of my gwt app.
My app uses a lot of rpc request, so i am trying to caching them in the client.
Each rpc request returns a list of records (normally 100 records). I'am storing them in the client as a Java List, but I notice that the browser can not carry ok with this amount of objects. It performance cracks.
I'am thinking of storing the result of each request into a cookie using some kind of JSON and retrieving it when needed. In other words, caching the request in cookies better than in the RAM of the client browser.
Can somebody suggest me anything?
Will I success by following this approach or is this a stupid think?
Does anybody has a better solution?
Maybe you want to have a look at this question: Client side caching in GWT
Cookies are actually a terrible place to store stuff, because they get sent to the server on every request, even RPC (Ajax) requests.
I think what you want is local storage, which has some kind of implementation in every modern browser. Not sure about older IE's but you could fall back to Flash for local storage there.
Edit
GWT doesn't have any native support for local storage (that I know of) but you could always use JSNI for that.
Also storing stuff in JS is a perfectly valid way to do it, you just need to make sure stuff expires and falls out of the cache. Is your current cache solution just growing forever? Because that certainly will kill the browser eventually.
The cookie is sent as a field in the header of the HTTP response by a web server to a web browser and then sent back unchanged by the browser each time it accesses that server.
think about the traffic...
#darkporter I completely agree and would like to add that Web Storage support are coming in the next GWT 2.3 release. So if you need it right now, you could pull those classes from gwt trunk and use them in your project.

Resources