Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm wondering if someone could help me understand how this works.
When I use AJAX (with jQuery or plain XMLHTTPRequest), I can see a request in the console labeled XHR, that's fine, I understand this.
When I try using the Google Places Autocomplete, and I monitor the requests in the console they're not labeled as XHR but GET. You may see it here - try the autocomplete search and see the requests in the console.
Are those AJAX requests too? If so, why aren't they labeled as XHR? If not, how is it being handled? Is a plain GET faster than XHR?
The responses are scripts. They are using JSONP which is a hack used to work around the Same Origin Policy which was commonly used before CORS was introduced.
Are those AJAX requests too? If so, why aren't they labeled as XHR?
They are Ajax requests, but they work by injecting <script> elements into the page instead of using XMLHttpRequest.
Is a plain GET faster than XHR?
A GET request is a GET request. It doesn't matter if it is initiated by injecting a <script> element or using XHR. The HTTP request is still the same.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm writing a bot with plain javascript that sends requests to a certain website without node.js or dependencies like jquery. I want to send every requests through a proxy, but I can't figure out how to do that with vanilla js.
I don't know where to even start. I've read the xhr documentation and found nothing about proxies. Google yielded nothing too.
Thanks!
There are two broad categories of proxy server (that we need to care about for the purposes of this question).
Ones designed to be set up as an HTTP proxy for a client. These require that the client be configured to use the proxy (for example, see this university's guide to using their proxy). You cannot use client-side JavaScript to make a browser use this kind of proxy.
Ones which present as a regular HTTP server but which determine what response to make by making an HTTP request to a different server (as opposed to reading a static file or executing a CGI program). To use these: Just make an HTTP request to a URL hosted by the proxy server.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to solve a problem similar to the ones in this question and this one, basically tracking a sub-session for users by browser tab. The thing I'm trying to accomplish, though, is finding a way to set a request parameter to send back to the server with each request, whether it's a simple synchronous link click, a form post, or an ajax request. What occurred to me as a hopeful solution would be if I could set something in the html head that would be sent each time, though I haven't seen anything to suggest that it's possible. I'm hoping to find a solution that doesn't require wrapping all server requests in some sort of javascript to include the desired parameter.
We're using Rails on the backend.
Difficult question to answer without knowing which server side language you are using. Regardless, using php, perl, python, or any other language, you could generate a unique ID and append it as a query string to your links. If you don't want the ugly links, you can:
A. use .htaccess to perform a mod_rewrite to clean up the URL
B. use an additional cookie to track the sub-session
C. use pure javascript, not very reliable depending on the client browser though..
the method used to track depends on what capabilities you have, database, text file, etc.
Again, not much info to go on.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I want to inject some javascript code during HTTP call before onload function is called. How can i achieve this? Is this even possible? I have achieved this using Chrome extension but I want some other method to inject the code which works on all other browsers. Something like injecting through URL bar while opening the page. This injection should work on all sites i open.
Another neat way to do it is to have the request go through a proxy. The proxy can inject the JS by modifying the source before it arrives to the client. This is how most ad-supported (ad-injecting) proxies do it.
But then, it's a security issue. That's why, same as having to tell the user to install an extension, you'd have to tell the user to use the proxy. Otherwise, it's a no-go.
Yet another way to do it is to have the owners of the site embed a script that points to a permanent path. Behind that path, you write any script, which may include one that loads some more scripts.
It can be as short as:
<script src="path/to/a/permanent/location"></script>
This is typically how publicly served APIs work, like Google. Behind their permanent path is a script that loads all the APIs you need. But, like I said in the previous section, you need permission, this time in the form of having the webmaster embed the script on the page.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am trying to redirect users to a specific page after a login. Are both equally effective? or is one better than the other?
Thanks
You cannot compare both methods!
JavaScript will only run on the client side, therefore you need to send HTML first, then execute the redirection.
Using PHP, you can directly forward the user. This is not only faster, but also the only applicable choice in terms of usablity.
You will also have a problem if JavaScript is disabled or you have got an error in your JS scripts (for whatever reason). Well, you could counter by using HTML meta redirects, but the pros of using server-side redirects just predominate.
Compared to client side JS, an HTTP redirect will:
Require less data to be send to the client for it to process the redirect instruction
Not cause the browser to behave badly when the back button is pressed
Work in browsers with JS blocked / disabled / otherwise failing
An HTTP Location header is almost always the better approach.
They are different.
One is server side (php) and the other is client side (js).
Usually it's done server side, so it's a transparent redirection (doesn't pollute browser history, back button, etc). I repeat: usually but it's not a rule.
PHP is faster - the whole page doesn't have to load first. You can just send the header and exit the script.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I want to request a list of sizes from a database on my server (which is obviously not on ebay.co.uk's domain). I could do it entirely through flash... but it seems clumsy for a simple form. I think the ideal solution would be a javascript + flash solution. The problem is all of the sites I have found seem to have very complete solutions and ebay does not like huge chunks of javascript (I am not sure exactly which functions it allows and doesn't... but the less javascript the better).
So what I am looking for is a very small and simple cross domain ajax solution that will allow me to make requests from my server. Anyone any ideas?
TIA
Read Ways to circumvent the same-origin policy for many ways of circumventing the same-origin policy.
In your case, I would suggest http://anyorigin.com - it's simple to use and (unless you're sending volatile information) perfectly viable. It could all be done in a couple of lines of js!
eBay will not allow including javascript or even iframes in item description.
The only solution for that will probably be using Flash object(that is allowed by eBay) that will communicate with server side scripting page(php/asp) which will make the request to your database.
The cross-domain communication will be between the flash and the server side page, this issue can be easily solved.