Sending 'large' amount of data cross-origin - javascript

I have a javascript bookmarklet which creates a screenshot of an element and saves it as a base64 encoded string.
Now, I need to send that image/string to my own server to save it. Only problem is that it's 6000+ characters long, or about 61 KB, making it unrealistic to GET it back to my server.
Is there some sort of external service that would somehow retrieve it back on my server? How can I send this image to my server?

Use POST.
Option A.) Use JavaScript to create a form, and post the data. If you do not want the page location to change, set target of the form to a hidden iframe.
If you need to get a response back from your server after the post, add a unique key to the form that you post, like <input type="hidden" name="key" value="..."> and then after the post is done use JSONP to get the response, like http://yourserver.com/donepost.php?key=.... Since you can't be sure that the post will complete before the JSONP call is made, you'll need to keep rechecking the server until a valid response is available or it times out.
Option B.) Post using AJAX. Set the Access-Control-Allow-Origin header on your server to allow this.

Related

Ajax Post request get converted to GET [duplicate]

I am having a very hard time understanding the exact process of "post/redirect/get".
I have combed through this site and the web for several hours and cannot find anything other than "here's the concept".
How to understand the post/redirect/get pattern?
Wikipedia explains this so well!
The Problem
The Solution
As you may know from your research, POST-redirect-GET looks like this:
The client gets a page with a form.
The form POSTs to the server.
The server performs the action, and then redirects to another page.
The client follows the redirect.
For example, say we have this structure of the website:
/posts (shows a list of posts and a link to "add post")
/<id> (view a particular post)
/create (if requested with the GET method, returns a form posting to itself; if it's a POST request, creates the post and redirects to the /<id> endpoint)
/posts itself isn't really relevant to this particular pattern, so I'll leave it out.
/posts/<id> might be implemented like this:
Find the post with that ID in the database.
Render a template with the content of that post.
/posts/create might be implemented like this:
If the request is a GET request:
Show an empty form with the target set to itself and the method set to POST.
If the request is a POST request:
Validate the fields.
If there are invalid fields, show the form again with errors indicated.
Otherwise, if all fields are valid:
Add the post to the database.
Redirect to /posts/<id> (where <id> is returned from the call to the database)
I'll try explaining it. Maybe the different perspective does the trick for you.
With PRG the browser ends up making two requests. The first request is a POST request and is typically used to modify data. The server responds with a Location header in the response and no HTML in the body. This causes the browser to be redirected to a new URL. The browser then makes a GET request to the new URL which responds with HTML content which the browser renders.
I'll try to explain why PRG should be used. The GET method is never supposed to modify data. When a user clicks a link the browser or proxy server may return a cached response and not send the request to the server; this means the data wasn't modified when you wanted it to be modified. Also, a POST request shouldn't be used to return data because if the user wants to just get a fresh copy of the data they're forced to re-execute the request which will make the server modify the data again. This is why the browser will give you that vague dialog asking you if you are sure you want to re-send the request and possibly modify data a second time or send an e-mail a second time.
PRG is a combination of POST and GET that uses each for what they are intended to be used for.
Just so people can see a code example (this is using express):
app.post('/data', function(req, res) {
data = req.body; //do stuff with data
res.redirect('public/db.html');
});
So to clarify, it instantly refreshes the webpage and so on refresh of that webpage (e.g. if you updated an element on it) it won't repost the form data.
My code used to look like this:
app.post('/data', function(req, res) {
data = req.body;
res.sendFile('public/db.html');
});
So here the response is sending the html file at the /data address. So in the address bar, after pressing the submit button it would say for me: localhost:8080/data.
But this means that on refresh of that page, if you have just submitted the form, it will submit it again. And you don't want the same form submitted twice in your database. So redirecting it to the webpage (res.redirect) instead of sending the file (res.sendFile) , stops the resubmission of that form.
It is all a matter of concept, there is no much more to understand :
POST is for the client to send data to the server
GET is for the client to request data from the server
So, conceptually, there is no sense for the server to answer with a resource data on a POST request, that's why there is a redirection to the (usually) same resource that has been created/updated. So, if POST is successful, the server opiniates that the client would want to fetch the fresh data, thus informing it to make a GET on it.

Javascript http post into form

var dataToSend = "randomStuff";
I want dataToSend to be send via POST into
<textarea class="form-control" name="list" rows="1" id="comment"></textarea>
this specific textarea is not local, its a random html page.
How do I do that?
I've tried several things, but nothing seems to work. Can someone bring me onto the right path? (Without jquery if possible, but appreciate any suggestions,...)
Thank you.
You can't. That isn't how POSTing works.
When you make an HTTP request you can include data in in various ways (the query string on the URL, the body of the request, cookies, custom HTTP headers, etc). When people talk about POSTing data, they usually mean the body of the request.
The data is sent to the HTTP server that the URL points to.
It is the responsibility of the server (or possibly JavaScript embedded in the document returned by the server) to do something with that data.
It could read data from the request and put it in then HTML document it responds with. That technique could be used to set a default value for a textarea.
The important point is that it is the responsibility of the site providing the textarea.
There is no way for code on a website to populate the value of a textarea on an arbitrary third party site.
It is, however, possible to make a POST request to the end point that the form containing the textarea points to.
The simplest way is to make a form with the same action and a form control with the same name (list).
That form could be populated and submitted by JavaScript since it is on the same page.

Passing large amounts of data from one page to another without POST?

I'm using a web server framework which works with only GET requests, at the moment I'm trying to pass a large amount of data, that is the text content in a textarea which comes from user input, into another page which echoes the user's input.
I've attempted Querystrings but I end up receiving the error "Requested URL too long".
Any suggestions as to what method I should use?
If you can only send data encoded in GET requests, then you will have to break up the request and send it in multiple parts.
You could either use Ajax or store the entire set of data in localStorage and fetch each chunk in turn as the page reloads.
One approach would be to make a request to an end point that allocates you a unique ID. Then send a series of requests in the form: ?id=XXX&page=1&data=... before closing it with ?id=XXX&total_pages=27 at which point you assemble the different pieces on the server.
This way lies madness. It would be much better to add POST support to your framework.
Try using Javascript Cookies.
you can store the textarea value there and then read it in another page (or wherever you want).
Here's a tutorial
http://www.w3schools.com/js/js_cookies.asp

Cross Domain File Upload Solution For All Browsers?

Here's my problem:
I have 2 web applications and want to upload a file from 1st to 2nd one. So I have to face with 'Same Origin Policy' issue.
In my case I own the 2nd Website and the 1st one is not mine. It's for my new customer of my existing web application and is developed with php and due to my lack of php knowledge I can't do server-side php coding. So I only can put some JavaScript code into one of its pages. So I don't have the proxy server option either.
And the third problem is I have to get this file uploading work in all browsers (including IE8+); so I also can't use the File API and XHR.
Any solution to my nightmare?
I don't know how much data you need to send upstream, however, here are two options:
1) MAKE AN IMAGE REQUEST THAT CONTAINS ALL PERTINENT DATA IN THE URL:
Parse the data you want to send upstream into query string parameters that get submitted to a special web service that knows how to read and collect this data from the URL. The server response should be empty. NOTE: URLs should not exceed 2000 characters. If you have a large data set, you will want to use option 2.
EXAMPLE:
/* I'd recommend doing the following with jQuery or some other JS framework */
var img = document.createElement('img');
img.src = "http://website2.com/uploadHandler" +
"?data1="+encodeURIComponent(data1) +
"&data2="+encodeURIComponent(data2);
document.getElementsByTagName("body")[0].appendChild( img );
OUTPUT (at end of body tag):
<img src="http://website2.com/uploadHandler?data1=myName&data2=myInformation" />
This will cause a HTTP GET request to be made to your server at the above address. The trick is that you're not actually going to serve an image but rather collect data from the request.
2) FORM POST:
Use javascript to create a form and populate that form with input fields containing the data you wish to upload. You can automatically submit this form using myForm.submit(). Using jQuery this would look something like:
$(document.body).append( $('\
<form name="myform" action="http://website2.com/uploadHandler">\
<input type="text" name="data1" value="myName" />\
<input type="text" name="data2" value="myInformation" />\
</form>') );
document.myform.submit();
Using this technique will cause a new page to load. However, you could use a redirect on the server side to redirect to the original page. Read the following if you choose to redirect: http://www.theserverside.com/news/1365146/Redirect-After-Post

Use hidden iframe to submit data

I need to submit some information to my servlet. Once I submit this information, I'll receive a PDF from the servlet based on the data. I know I can construct the URL and pass parameters to it using HTTP GET. Suppose my form data is too large.So is it possible to do this using a hidden iFrame? I'll submit the parameters using the hidden iFrame and in my servlet, I write the PDF to the response stream. Will this work? If it works can someone please suggest me how to do this?
You'll need to set the target to the iframe you want to submit it to.
<form action='...' name='theform' target='theiframe'>
.
.
.
<iframe name='theiframe' src='...'>
</iframe>
</form>
This forum post has some details : http://forums.powweb.com/showthread.php?t=77213
Hm, which way do you want to sent the data using your iframe? I think you're limited to either GET or POST there, too. Means, if your data is too large, the iframe won't help sending your data.
What server backend do you use? You might be able to configure the maximum size of request data (post / get).
Please have a look at this message for more information about this.
In my eyes, using the hidden Iframe method is very old school, almost like before the great days of Ajax methods.
You can use jquery Ajax call and serialize your full form passing all variables. Remember to check your request size in your config, in case it post reaches maximum size.

Categories