Security Software Conflicts with AJAX? 84
ithyus needs help with the following: "My employer is running an e-commerce site that, until recently, our customers were quite happy to use. With increased traffic to the site we decided to implement AJAX to try to reduce the load on our database servers. In doing so, our customers have experienced all kinds of problems with security/privacy software such as Norton and McAfee. It seems that no matter what we do we can't make these programs happy. Bigger companies such as Google have documented work arounds for some of them, but we wouldn't be able to keep our docs current with all the software that's presently out there. I'd really like to know how Slashdot's readers have handled these issues. Since security programs don't appear to be compatible with the emerging features of the Internet, do you simply suggest that the customer disable the offending software or do you opt to offer some support for the more popular ones? Are those really the only two options? How do you justify your method?"
Answered Own Question? (Score:4, Insightful)
Don't ask customers to be vulnerable (Score:3, Insightful)
You know... (Score:5, Insightful)
If you are designing programs that can be potentially used by many thousands of users, you can not afford to write programs that only cater for those who wish to play by *your* game. A good few of them will refuse and use another software.
NeoThermic
Graceful degradation usually fixes this (Score:5, Insightful)
The kinds of things security software disables should be non-essential anyway. For instance, ActiveX disabled in Internet Explorer will stop you from using XMLHttpRequest, but that throws an error that you can catch, and your fallback behaviour for non-JavaScript users can be used.
Whenever I see somebody complaining about software interference with web applications, it's virtually always because they've cut corners and neglected to code appropriate fallback behaviour when browsers don't support a particular feature. Unfortunately, it's impossible to give you specific advice because you've unhelpfully neglected to mention anything specific at all about the problems you are having.
As somebody else mentioned, if your goal is to reduce load on your databases, then this can be achieved through other means. For instance, caching (both page fragments, and HTTP caching) can significantly reduce load if most of your transactions are reads that apply to multiple users.
Re:Haven't run across this yet (Score:3, Insightful)
AJAX is just another way of sending http requests to the server from the browser.
Unfortunately this alternate method makes use of a couple of potentially harmful mechanisms: client side scripting and (in IE) ActiveX. Additionally, it is not uncommon to see AJAX requests and responders bend or break the rules of HTTP also which can cause packet-inspecting firewalls some grief. Sure, you can easily code up a little shopping site where you click 'show price' to load the price via AJAX, but it's no excuse for not making that same link do the right thing in browsers that do not have that capability.
If it's Norton Internet Security (Score:3, Insightful)
Norton is the only thing I've ever seen decide that outbound DNS queries were *all* suspicious and should be silently blocked.
I don't get it... (Score:3, Insightful)
And why do you think that "implementing AJAX" would magically reduce the load on database servers? The load on database server is purely dependant on the data you are storing and the queries you're doing in order to access it. Sure, you could be able to avoid certain queries hitting the database by firing the queries only after the user does something on the web interface. But on the other hand, this is not magic bullet for sure. If you don't know what you're trying, you might find yourself in a situation where your web and database servers are hammered with say 10x increase in requests/queries.
Re:Just stop using Ajax (Score:5, Insightful)
This indicates a complete lack of understanding of why developers are turning to AJAX. The point is not that they want to foist their server load problems on the client. The point is that they are trying to give their users a more responsive experience. Reducing the burden on the server is one effective way to do this.
When we were all on the far end of 14K4 modems, a few seconds of latency at the server went more or less unnoticed. Now that most of us have broadband, people complain if the information does not at least appear to arrive instantly. AJAX, when used properly (and I concede that it is not always used properly) is about having web sites that only move the change information back and forth, without moving all of every page when little has changed. This reduces the traffic between the client and server in both directions and can improve responsiveness as a result. Google Maps [google.com] is a classic example of this; by moving the map tiles around locally in JavaScript and only asking the server for the missing tiles as they are needed makes for a much more interactive experience. The fact that the map tiles are all static content is a bonus, but it's not the end goal.
Re:I don't get it... (Score:3, Insightful)
In terms of AJAX reducing DB queries, it works as follows. In traditional web apps, you often have data that gets reloaded repeatedly. For example, a list of products. The user clicks on a product, looks at it, clicks back to the list (causing a db query on the page refresh). Now, in AJAX, the user clicks on a product, which hides the list. In place of the list the product details are shown. Clicking the link to the list hides the product details and shows the list (no page refresh so no db query). If your main use case is people clicking back and forth between pages (e.g. to compare products), then using AJAX significantly reduces the page hits.
Others have pointed out that server side caching does the same thing (relative to the database). The problem comes when you have a lot of clients relative to the size of your server cache. Server caches work best when multiple clients can share a cache. In this situation, each client might be looking at different products, which causes thrash (there is more info than fits in the cache).
Sure, you can write AJAX apps in such a way that they increase the DB load. AJAX is not magic; it won't auto-solve issues. However, AJAX can be used to rewrite an existing app to reduce page queries. The reduction in page queries will reduce DB load in many situations.