Why is it bad to not set the X-request-with XMLHttpRequest for CORS OPTIONS preflight request?

[karendolan]

Description

I've been spending a lot of time debugging a Safari oddity with cached CORS images. It doesn't happen in Chrome or Firefox. Safari sends a CORS preflight request on a cached redirect images and the preflight request is rejected because of the nuances of headers and redirects. So, the image doesn't load. And the recommendation is not to use Safari browser for a large number of users. The reason I'm writing a jQuery ticket is that I discovered if add a breakpoint on the xhr.send https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js#L99. And break that send, the image loads no problem. Safari can be used again. For this large user app (Canvas Instructure LMS), the jQuery is v1.7.2.

My Question

In Dec 9, 2010. jaubourg authored and jeresig committed on Dec 9, 2010, a fix that solves my problem here in Sept 2021
"Rewrite of the Ajax module by Julian Aubourg. Some (dated) details can be found here: http://oksoclap.com/6Y26bm1ZsB more details are forthcoming. Fixes #719 "

				// Requested-With header
				// Not set for crossDomain requests with no content
				// (see why at http://trac.dojotoolkit.org/ticket/9486)
				// Won't change header if already provided in beforeSend
				if ( ! ( s.crossDomain && ! s.hasContent ) && ! headers["x-requested-with"] ) {
					headers["x-requested-with"] = "XMLHttpRequest";
				}

ab3ba4a#diff-cb705ccef09991ea3b7663785131bf2dR35-R41

But, then in Mar 6, 2011, that fix was reverted with "Fixes #8423. Never set X-Requested-With header automagically for cross-domain requests." 6c124d3

-					// Requested-With header
-					// Not set for crossDomain requests with no content
-					// (see why at http://trac.dojotoolkit.org/ticket/9486)
-					// Won't change header if already provided
-					if ( !( s.crossDomain && !s.hasContent ) && !headers["X-Requested-With"] ) {
+					// X-Requested-With header
+					// For cross-domain requests, seeing as conditions for a preflight are
+					// akin to a jigsaw puzzle, we simply never set it to be sure.
+					// (it can always be set on a per-request basis or even using ajaxSetup)
+					// For same-domain requests, won't change header if already provided.
+					if ( !s.crossDomain && !headers["X-Requested-With"] ) {
						headers[ "X-Requested-With" ] = "XMLHttpRequest";
					}

Would it be inclusive of both fixes to not add the header if (a) it's a CORS with no content and (b) it's not a CORS,
By combining both fixes in the following?

					// Requested-With header
					// Not set for crossDomain requests with no content
					// (see why at http://trac.dojotoolkit.org/ticket/9486)
					// Won't change header if already provided
					if (( !s.crossDomain ||  !( s.crossDomain && !s.hasContent ))
                                              && !headers["X-Requested-With"] ) {
						headers[ "X-Requested-With" ] = "XMLHttpRequest";
					}

Link to test case

To duplicate:

1. Open Safari browser
2. Go to this site https://cidilabs.instructure.com/courses/3/pages/upload-slash-embed-image-test . That link is public and might change. To duplicate the scenario, open a Canvas LMS, upload and image, refresh the page.
3. Refresh the page to see the broken image link. Refresh a few more times to verify the issue with the broken image request is really stuck.
4. Open Safari inspector, go to console. Reload the page. See the CORS preflight error.
5. In Safari inspector, go to the Sources tab, search by type, search for "jquery" under node_modules/jquery path.
6. In the jquery source, place a breakpoint on line 7487 "xhr.send( ( s.hasContent && s.data ) || null );"
7. reload the page and let it debugger hang at your breakpoint.
   After a bit, the image will load. Thereafter, reloading that page will load the image.

[mgol]

@karendolan Thanks for the report.

It's a bit unclear to us why setting the X-Requested-With would help your case; in the "Description" section you wrote Safari sometimes sends a preflight request when not expected; why adding this header solves the issue? Also, you wrote that pausing the script just before sending the request followed by sending it manually helps; that suggests possible issues with a script running side by side. It'd be good to have a test case not dependent on a specific full site. Ideally, it'd be reduced so that it doesn't even require usage of external libraries.

As for the code sample, I think there's a mistake here - you wrote (module code formatting):

( !s.crossDomain || !( s.crossDomain && !s.hasContent ) ) && !headers[ "X-Requested-With" ]

but I think you want:

( !s.crossDomain || ( s.crossDomain && !s.hasContent ) ) && !headers[ "X-Requested-With" ]

which is the same as:

( !s.crossDomain || !s.hasContent ) && !headers[ "X-Requested-With" ]

[karendolan]

Hi @mgol , you are correct, I was looking to avoid adding the X-Requested-With header when the request is cross-domain but does not have content.

The idea is to simplify GET requests for CORS cached images, to prevent Safari from preforming a preflight OPTIONS request altogether for them, like Chrome & FF. The X-Requested-With is one of the headers in a GET request that seems to spark the OPTIONS preflight from Safari. GET requests don't have content but can be CORS.

I'm not completely convinced avoiding that one header will prevent the OPTIONs launch for cached CORS content in Safari. I will try run a local test with the modified jQuery to verify the proposal from this ticket.

[mgol]

Hi @mgol , you are correct, I was looking to avoid adding the X-Requested-With header when the request is cross-domain but does not have content.

But the header is already not set for any cross-domain request; the code in v3.5.1 is:

if ( !options.crossDomain && !headers[ "X-Requested-With" ] ) {
	headers[ "X-Requested-With" ] = "XMLHttpRequest";
}

so the header is set to "XMLHttpRequest" only if the request is same-domain and the header is not already set.