I am using Ajax to retrieve images from a remote server. First I try this directly using the URL of the remote server - the returned image is a string(since that's how Ajax communicates). I use the Javascript fromCharCode and CharCodeAt to convert the data back to binary and then the window.btoa() to display it. This works. Then I want to transfer this image through an overlay network (P2P). I intercept the Ajax request, transfer it to the server through the P2P network and then retrieve the response in []byte array. But now I need to know to what type of string I should convert the byte array before I feed it back to the calling Ajax client. If I use Base64 or simply convert the byte array to string it does not display the image correctly.
Anyone has tried working with something like this before?
I will appreciate any feedback very much. Thanks
Javascript doesn't have different kinds of strings.
The desired character set will be the same one the web page is encoded in, ideally UTF-8.
Have you compared the response sent by the P2P server to the response sent by the original server? Is there some kind of wrapper that's missing, or perhaps an important MIMEtype difference?
Related
i'm trying to scrape a website but the thing is that i get this as a response (most likely javascript ? ). I am using request in order to send requests to the website.
Is it possible to convert it to a parsable format ? I thought of using jQuery to send request an accept a certain response format.But as of right now i'm mainly trying to identify the type of response i'm getting. Thank you.
The response i get :
Likely gzip
https://en.wikipedia.org/wiki/List_of_file_signatures
Click F12 and look at the response in a browser.
HTML is often gzipped and if you are not using a client that unzips it, then you will get the raw zip
How to understand a website is using gzip compression?
Client vs server imagen process.
We got a big system which runs on JSF(primefaces) EJB3 and sometimes JavaScript logic (like for using firebase and stuff).
So we run onto this problem, we have a servlet to serve some images. Backend take a query, then extract some blob img from DB, make that BLOB into array of bytes, send it to browser session memory and servlet take it to serve it in ulr-OurSite/image/idImage. Front end calls it by <img>(url/image/id)</img> and works fine so far.
Then we are using a new direct way to show img, we send BLOB/RAW data to frontend and there we just convert them into Base64.imageReturn. and pass it to html.
Base64 codec = new Base64();
String encoded = codec.encodeBase64String(listEvidenciaDev.get(i).getImgReturns());
Both work, for almost all cases.
Note: We didn't try this before because we couldn't pass the RAW data through our layers of serialized objects and RMI. Now we can of course.
So now there are two ways.
Either we send data to servlet and put it on some url, which means the backend does all the job and frontend just calls url
or we send data to frontend which is going to make some magic and transform it to img.
This brings 2 questions.
If we send to frontend RawObject or make them call URL to show his image content, final user download the same amount of data? This is important because we have some remote branch offices with poor internet connection
Is worth pass the hard work to frontend (convert data) or backend (convert and publish)?
EDIT:
My questions is not about BLOB (the one i call RAW data) being bigger than base64
It is; passing the data as object and transform it to a readable picture is more heavy to internet bandwidth than passing a url from our servlet with the actual IMG and load it on html ?
I did choose to close this answer because we did some test and it was the same bandwidth usage on front end.
Anyway we make use of both solutions
If we dont want to charge frontend making a lot of encode we set a servlet for that images (that comes with more code and more server load). We look for the best optimization on specific cases.
I'm trying to do client-side processing of some data sent in a server's HTTP response.
Here's what I'm working with: I have a web application that sends commands to a backend simulation engine, which then sends back a bunch of data/results in the response body. I want to be able to access this response using JavaScript (note..not making a new response, but simply accessing the data already sent from the server).
Right now, I am able to do this via a kludgy hack of sorts:
var responseText = "{{response}}";
This is using Django's template system, where I have already pre-formatted the template context variable "response" to contain a pre-formatted string representation of a csv file (i.e., proper unicode separators, etc).
This results in a huge string being transmitted to the page. Right now, this supports my immediate goal of making this data available for download as a csv, but it doesn't really support more sophisticated tasks. Also, I'm not sure if it will scale well when my string is, say, 2 MB as opposed to less than 1 KB.
I'd like to have this response data stored more elegantly, perhaps as part of the DOM or maybe in a cache (?) [not familiar with this].
The ideal way to do this is to not load the csv on document load, either as a javascript variable or as part of the DOM. Why would you want to load a 2MB data every time to the user when his intention may not be to download the csv everytime?
I suggest creating a controller/action for downloading the csv and get it on click of the download button.
I am creating a web API with Node.js and Express and intend to use a single response to return an image and JSON data simultaneously. I saw a solution to specify headers: https://stackoverflow.com/a/18864738/1703565 but I do not want to perform two get requests. How do I accomplish this?
You could encode the image as a base64 string (http://nodejs.org/api/buffer.html#buffer_buf_tostring_encoding_start_end), and return this as part of your JSON.
Cookies
You could return the image as a normal image response body and then set a session cookie with the same request. The session cookie would contain the JSON data. Once the image loads you can pull the JSON data from the cookie via javascript.
This would work in all browsers. Only limitation would be the size of the JSON you could return. Max size looks to be 4093 bytes.
Image Encoding
If your JSON is too big to fit in a cookie then you could encode the image as a base64 object and return the image data in the JSON response.
In this case you would have to reconstruct the image on a canvas or use the image data url format to dynamically create an image object as the url in the comment from Kevin does.
One downside to image encoding would be the increased size of the response. Roughly, the size of the image after encoding in base64 would be 37% larger than the original image.
Ultimately it depends on your specific needs as to which method would best fit your requirements.
I am making an application that will store a Azure SQL server DB user information, including profile photo downloaded from Facebook. On the server side, ASP.NET MVC4'll have a controller that will receive the information and send it to the database.
The client side is Javascript and thought to give the image in json (once converted to base64). Is it a good option? Is it better to directly send the jpg? What are the advantages of sending information in json?
In SQL Server image field would be stored as a nvarchar (max)
Are you going to return the image as a binary stream content type image/jpeg or as a text stream encoded base64? Is far more likely that you're going to do the former, so there is little reason to go through an intermediate base64 encoded transfer. And of course, store them as VARBINARY(MAX). Even if you would choose to store them as base64, choosing an Unicode data type for base64 text is really wasteful, (double the storage cost for no reason...), base64 can fit very well in VARCHAR(max).
But, specially in a SQL Azure environemnt, you should consider storing media in Azure BLOB storage and store only the Blob path in your database.
In my opinion, it's better sending the image directly in .jpg using Multipart Forms or something like that.
Sending information in Json is useful when you transfer explicit data, like collections or objects that you will be able to query or de-serialize later.
The client side is Javascript and thought to give the image in json (once converted to base64). Is it a good option?
As Pasrus pointed out, you are not going to manipulate the image data. So JSON does not seems to be a good choice here.
One option is, you can add the base64 data into src attribute in html tag and send it.
What are the advantages of sending information in json?
Please check this answers and there are so many:
Advantages of using application/json over text/plain?
In SQL Server image field would be stored as a nvarchar (max)
Please refer this link:
Storing images in SQL Server?