I wonder if AJAX can use protocols other than HTTP or HTTPS.
Ajax means XMLHttpRequest. Just as you don't have to use XML with XHR, you also don't have to use HTTP.
Despite its name, XMLHttpRequest can be used to retrieve any type of data, not just XML, and it supports protocols other than HTTP (including file and ftp).
From the W3C XMLHttpRequest spec (emphasis added):
The XMLHttpRequest object implements an interface exposed by a scripting engine that allows scripts to perform HTTP client functionality, such as submitting form data or loading data from a server. It is the ECMAScript HTTP API.
The name of the object is XMLHttpRequest for compatibility with the Web, though each component of this name is potentially misleading. First, the object supports any text based format, including XML. Second, it can be used to make requests over both HTTP and HTTPS (some implementations support protocols in addition to HTTP and HTTPS, but that functionality is not covered by this specification). Finally, it supports "requests" in a broad sense of the term as it pertains to HTTP; namely all activity involved with HTTP requests or responses for the defined HTTP methods.
The available protocols beyond HTTP and HTTPS are non-standardized, so they depend on the specific environment1 you're using. That is, all compliant XHR implementations must support HTTP and HTTPS, but are not required to support any other specific protocols. That means that you might find that Internet Explorer supports
1Such as, which version of which browser (Safari vs Firefox vs Chrome vs IE vs Opera vs...), or which server-side implementation (V8 vs Rhino vs...)
XMLHttpRequest (XHR) is an API available to web browser scripting languages such as JavaScript. It is used to send HTTP or HTTPS requests to a web server and load the server response data back into the script.
from wikipedia
Related
I am trying to perform an AJAX request from my site which is deployed on 'HTTPS' protocol. but the request I am making to is deployed on 'HTTP' protocol.
So I am getting the following error:
This request has been blocked; the content must be served over
HTTPS
My Request is as follows:
$.ajax({
url: "http://testsite/service/process.php",
type: "POST",
data: { service: '#service', id: '#id' }
});
Is there any way/trick to bypass this error/issue without changing
anything at ServerSide (http://testsite/) or Is it necessary to
ENABLE/CONFIGURE C.O.R.S on Server Side because I have no controll over Server Side.
Alternatives to CORS
If your web application must run in browsers that do not support CORS or interact with servers that are not CORS-enabled, there are several alternatives to CORS that have been utilized to solve the cross-origin communication restriction.
JSONP. This is a technique that exploits the HTML script element exception to the same-origin security policy. Script tags can load JavaScript from a different domain and query parameters can be added to the script URI to pass information to the server hosting the script about the resources that you wish to access. The JSONP server will return JavaScript that is evaluated in the browser that calls an agreed upon JavaScript function already on the page to pass server resource data into your page.
OpenAjax Hub. This is an JavaScript Ajax library that allows integration of multiple client-side components within a single web application. Trusted and untrusted components to co-exist within the same page and communicate with each other as long as they all include the OpenAjax Hub JavaScript library. The framework provides a security manager to allow the application to set security policies on component messaging. Iframes are used to isolate components into secure sandboxes.
easyXDM. This is a JavaScript library that allows for string-based cross domain communication via iframes. It works on the same principals as OpenAjax Hub but does not have the security manager component.
Proxied Iframe. This do-it-yourself technique involves including an iframe on your page from the domain you wish to communicate with. This assumes that you are able to host pages on this other domain. The JavaScript running in the iframe serves as a rest proxy to the server containing the resources you wish to access. Communication between your application and the rest proxy will take place using post message. Post message is part of the HTML5 standard, but there is also a jQuery implementation for non HTML5-compliant browsers.
I'm working on extensions for Firefox and Chrome. The data used by my extensions is mostly generated from ajax requests. The type of data being returned is private, so it needs to be secure. My server supports https and the ajax calls are being sent to an https domain. Information is being sent back and forth, and the extensions are working correctly.
My questions are:
Do the extensions actually make secure connections with the server, or is this considered the same as cross domain posting, sending a request from a http page to a https page?
Am I putting my users' information at more risk during the transfers than if the user were to access the information directly from an https web page in the browser?
Thanks in advance!
The browser absolutely makes a secure connection when you use HTTPS. Certainly, a browser would never downgrade the security of your connection without telling you: it will either complete the request as written or it throw some sort of error if it is not possible.
Extensions for both Chrome and Firefox are permitted to make cross-domain AJAX requests. In Chrome, you simply need to supply the protocol/name of the host as a permission in your manifest.json. In Firefox, I think you may need to use Components.classes to get a cross-domain requester, as described in the MDN page for Using XMLHttpRequest, but I'm not 100% sure about that. Just try doing a normal request and see if it succeeds; if not, use the Components.classes solution.
I'm interested if there is some tool (preferably a firefox addon) that allows you to record http requests and view their response header and content.
Try HttpFox :
HttpFox monitors and analyzes all
incoming and outgoing HTTP traffic
between the browser and the web
servers.
It aims to bring the functionality
known from tools like HttpWatch or
IEInspector to the Firefox browser.
Information available per request
includes:
- Request and response headers
Sent and received cookies
Querystring parameters
POST parameters
Response body
Firefox's firebug and webkits developer tools.
I recommend using Charles, http://www.charlesproxy.com/.
Charles is a stand-alone application, not a browser addon (but it has browser integration) which I personally prefer, since it can monitor http traffic also outside the browser, for example when a swf is run locally or from an IDE, or any other http traffic on your system.
If you prefer a browser addon, I believe Fiddler is quite popular, http://www.fiddler2.com/.
HTML5 will be next super star.
So~~~How to using new idea to implement AJAX on the WebSocket in HTML5 spec?
thx....
I think you misunderstand ajax and websockets.
All internet programs operate by using a special kind of connection known as a socket (sockets can also be used for other things, but thats not important right now). For example, when you access a webpage in Chrome, Chrome creates a socket and uses that to connect to the webserver (there are other steps, but thats the simple explanation).
Ajax is a method for updating content on a page without reloading that page (or going to a new page), this is useful for dynamic content. Ajax works through the XMLHttpRequest object in the DOM Api. When you make an Ajax request, you're asking the web browser to initiate a new connection on your behalf (the web browser may then create a new socket as it sees fit).
Websockets is an alternative api which allows you more control over the socket the web browser creates. In essence its an alternative technology which accomplishes a similar purpose. Ajax sends only a single HTTP request (usually post or get), and receives the appropriate response, thus the advantage of websockets are 2 fold:
Websockets allows for non HTTP transfers (for example, streaming VoIP).
Websockets allow for bi-direction transfers, (ie. servers making follow up requests to client).
This is not to say Ajax isn't still useful, but that Websockets allow you to do things you can't with Ajax.
Assuming a single page application accessed initially via HTTP that uses AJAX for all server interaction, is it possible to use HTTP for regular data transfers and then switch to AJAXian HTTPS requests for secure data transfers?
If so, how would the browser handle the certificate and locking notification when a HTTPS AJAX request was made?
If this is not possible, then are there any workarounds to mixing AJAX HTTP and AJAX HTTPS within the same page such as loading an iFrame for HTTPS?
Thanks!
Attempting to switch protocols will violate the same origin policy.
I am not sure how a workaround using iFrames would behave, but I think the browser may block access to the frame that was loaded as HTTPS, again due to the same origin policy.
I know this is old post but since i arrived here by search engine it would be a worth to spill what I've learn.
It is possible to use something called CORS but as usual old MSIE has problem implementing it.
It should be simple as sending additional HTTP headers:
Access-Control-Allow-Origin: http://example.com:8080 http://foo.example.com