Question

68

Understanding XMLHttpRequest over CORS (responseText)

rated 0 times [ 69] [ 1] / answers: 1 / hits: 81002 / 12 Years ago, thu, november 15, 2012, 12:00:00

For a project I'm looking at various HTML5 and Javascript elements and security around them and I'm trying to get my head around CORS just now.

Based on my testing, if I remove..

<?php

 header(Access-Control-Allow-Origin: *); 

 header('Access-Control-Allow-Methods: GET, POST, OPTIONS');

 ?>

..from the page that is trying to be accessed I see the following in the console log on Chrome:

XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.

I understand this to be correct, however Wireshark shows HTTP/1.1 200 OK in the return and in the data shows the source of the page being requested. So is it just the browser and Javascript that is blocking responseText from being used in any substantial way even though it's actually transferred?

The code is just as below:

  function makeXMLRequest() {

  xmlhttp=new XMLHttpRequest();

xmlhttp.onreadystatechange = function() {

    if (xmlhttp.readyState==4) {

        alert(xmlhttp.responseText);

    }

}

xmlhttp.open(GET,http://www.bla.com/index.php,true);

xmlhttp.send();

}

Thanks in advance.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

makiyac

Add To Favorites

Follow

Total Points: 470

Total Questions: 100

Total Answers: 115

Location: Botswana

Member since Sat, Jan 7, 2023

1 Year ago

makiyac questions

1 date-fns RangeError: Invalid time value

Sun, Jan 16, 22, 00:00, 2 Years ago

1 'Component' is not defined react/jsx-no-undef

Thu, Dec 17, 20, 00:00, 4 Years ago

1 Webpack; how to import css dynamically

Fri, Dec 4, 20, 00:00, 4 Years ago

1 Where to store user's credentials in React Native Mobile App

Sat, Aug 8, 20, 00:00, 4 Years ago

1 export 'AuthServiceConfig' was not found in 'angularx-social-login' in Angular 9 app

Wed, Jul 8, 20, 00:00, 4 Years ago

View All

answered 12 Years ago maxd · Accepted Answer

For a simple HTTP verb like GET or POST, yes, the entire page is fetched, and then the browser decides whether JavaScript gets to use the contents or not. The server doesn't need to know where the requests comes from; it is the browser's job to inspect the reply from the server and determine if JS is permitted to see the contents.

For a non-simple HTTP verb like PUT or DELETE, the browser issues a preflight request using an OPTIONS request. In that case, the browser first checks to see if the domain and the verb are supported, by checking for Access-Control-Allow-Origin and Access-Control-Allow-Methods, respectively. (See the Handling a Not-So-Simple Request on the CORS page of HTML5 Rocks for more information.) The preflight response also lists permissible non-simple headers, included in Access-Control-Allow-Headers.

This is because allowing a client to send a DELETE request to the server could be very bad, even if JavaScript never gets to see the cross-domain result -- again, remember that the server is generally not under any obligation to verify that the request is coming from a legitimate domain (although it may do so using the Origin header from the request).