An API returns large resultsets and I was wishing that I could gzip it in PHP but I wouldn't know how to gunzip it in Javascript. Is there some sort of library that is capable of this in Javascript? I was searching the net and found some stuff but couldn't quite figure out how to make use of it. So, if anybody has ever dealt with this before, advise is highly appreciated.
(The API response is worth about 1MB)
Usually compression of HTTP responses is done by either a proxy or a web server. You should be able to configure Apache to do this for you. See the documentation for mod_deflate for more information.
In terms of unzipping in JavaScript, this is a non-issue. Provided that the HTTP response contains the correct header information. (Content-Encoding: gzip) the browser will handle the unzipping for you.
Have the web server do it. Set the HTTP header to accept gzip when you send your request.
The web server and browser can usually handle the compression transparently, without needing php and javascript support. For example, a google search turned up: http://forums.digitalpoint.com/showthread.php?t=43
Related
I have a regular website with no login process. There was never anything on it that needed to be private so I'm using http. However I recently added an "E-mail Me" form, and some people might include sensitive information emailing me.
If the data is sent to my server with an Ajax $.post, can the data be read by someone watching the network traffic?
If so, Is there anyway I can secure it without switching to https?
OK: So def Yes to no 1.
For everyone that said no, why can't I use my own public-key/private-key for this?
If the data is sent to my server with an Ajax $.post, can the data be read by someone watching the network traffic?
Yes, for sure
If so, Is there anyway I can secure it without switching to https?
No, not really/practically.
You will need to use https, there is no other way to truly secure the information
The short answer is NO.
The long answer is that if you use js, the person monitoring the traffic will be able to know how you encode the data and easily decode it. If you use server side language (C# for example), the data will be transmitted as plain text to the server so the person monitoring the traffic will be able to read it clearly.
The only way is that you use a secure connection (HTTPS)
I apologize for what might seem like a really dumb question based on a limited of Node.js but please know I am attempting to learn all I can. That being said, as I understand it, Node.js is similar to Apache or IIS. What types of files does it actually serve though (ASP, ASP.NET, PHP, HTML, etc.)?
My IMPRESSION is that it serves JavaScript and HTML by recommendation? In such a case, if I write a JavaScript file used on the server side to write data to my database, is my code exposed to the end user?
My scenario for example is that I would write an HTML5 page with JavaScript to write to a database but if that is served by Apache or IIS then both the HTML and JavaScript have their code exposed. How does this work with Node.js, do I need to stay with PHP for securing my code?
Thank you!
As long as the server-side javascript isn't served to the requesting user you're safe. So no, the database stuff within nodejs won't be served.
That's like asking if PHPs or javas database code get served if someone requests a page (only if the code is read and echoed).
Node.js is a server-side scripting language with modules for interacting with HTTP requests and responses.
You can serve literally any kind of file with Node (as you could with other server-side scripting languages), and in fact, probably want to go out of your way not to let people grab any files they want.
PHP won't secure your code for you. Normally, nginx or Apache helps to protect against threats, but a Node.js server running on a port completely bypasses all of that unless you specifically configure nginx or Apache to forward requests to the port your node program is listening on.
Thinking about HTTPS, it is a compute-intensive protocol and one should only use it where necessary. I'm working on a web application and I will be using Angular.js MVC on the client side, calling into WebAPI REST Api returning JSON.
When I think about it I do not need to encrypt the HTML, the client-side javascript or styles sheet etc. After initial handshake only the data calls to the REST Api need encrypting.
Do other people do this? Are there any pitfalls or caveats?
Here's a great Mozilla article detailing their restrictions and why they exist.
Their recommendation is to always stick strictly to either HTTP or HTTPS.
Also, I suspect that browsers and web servers will greatly minimize the impact of encrypting the data over ssl on subsequent calls. I suspect if you profile it you'll find the impact minimal/non-measurable.
I have a node server that will serve more than 10,000 users at the same time with big data, I already tried lz-string https://www.npmjs.org/package/lz-string but it's not good module because it's blocking the node thread.
Please answer these questions:
is it better to compress the data in server and then decompress in client instead of send plain/json data?
what is the best and fastest way to compress/decompress the data?
If you are sending large chunks of text data over the internet using HTTP protocol, then there are already some technologies in place to help you.
One is called HTTP Compression. HTTP protocol specifications allow few compression algorithms to perform on data being sent, but that requires the server and client to be properly configured for compression. Standard Node.js server will not compress the data without modifying code.
For bare Node.js without any frameworks and 3rd party modules there is zlib module made specially for HTTP compression, both server and client.
Using Express? Then there is a compression middleware.
It might also be worth looking using nginx as a proxy server to your node.js applications. Then you can easily flip the switch ON for compression in nginx, without needing to do anything in your Node.js application at all:
server {
gzip on;
...
}
It really depends on the stack you are using, but the idea is same: compress the HTTP stream itself, as it is supported by the protocol.
I would like to test out some interviewees by having them write some javascript that will make requests against my server. I don't want to give them write access to my code base. Javascript runs on the client side, so this should technically be possible. However I know there are browser restrictions that say that the javascript has to come from the server?
I apologize that this is a really dumb question, but how should I proceed?
Edit:::
Ok, so I failed to mention that the entire application is based off sending JSON objects to and from the server.
I think you're thinking of the javascript XMLHttpRequest object itself, in which case, yes the current standard is for browsers to block cross-domain calls. So, you can tell them to pretend they either have a separate proxy script on their own personal domain which will allow them to leap to yours, or to pretend they're building a page directly served from your domain. There's talk of browsers supporting trust certificates or honoring special setups between source and target servers, but nothing universally accepted AFAIK.
Javascript source itself does not need to come from the server, and in fact this is how you can get around this little XMLHttpRequest block by using json. Here's a simple json tutorial I just dug up from Yahoo. But, this calls for your server to provide a json format feed if your server is the intended target.
"there are browser restrictions that say that the javascript has to come from the server"
I'm not aware of any situation where that's the case, only a lack of a console. But...even in those cases there's the address bar and javascript:.
If I misunderstood and you're talking about cross-domain restrictions, then your server needs to support JSONP for the requests so they can make cross-domain calls for data.
You could POST the javascript to your server and then your server can send back some HTML that has the javascript inlined. Sounds like you're trying to set up something is, more or less, a homebrew version of http://jsfiddle.net/; AFAIK, jsfiddle just does a "POST javascript/CSS/HTML and return HTML".