Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Description • 11 years ago

Attached patch hooks CORS tests up to workers and fixes a few bugs that the tests found.

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 1 • 11 years ago

With some test cleanups.

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 3 • 10 years ago

Updated, thanks to xKhorasan+mozilla@gmail.com

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 4 • 10 years ago

Anne, this patch exposes a problem in test_bug435425.html that sicking says needs spec direction to resolve.

Basically we have a XHR POST request that is initially same-origin and has upload listeners attached. We don't do a preflight and we fire a loadstart event on the upload object. Then we redirect to some cross-origin url. Currently we fire error/loadend events at the upload object. Is that correct? As I understand it we're not supposed to fire events on the upload object if we haven't done a preflight...

	Anne (:annevk)
	Comment 5 • 10 years ago

I think per the current specification that would require us to do a preflight before we do the cross-origin request as the mode is "CORS-with-forced-preflight" due to the listeners being attached.

	Ben Turner (not reading bugmail, use the needinfo flag!) Reporter
	Comment 6 • 10 years ago

Ok, sicking, what do you want me to do here?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 7 • 10 years ago

Comment 5 would violate two of the design patterns that I think we've aimed for:

1. It would force implementations to be able to do a preflight after the initial request has already started.

Right now the preflight either happens before the initial request, or it doesn't happen at all. It never happens as a result of a redirect.

Gecko used to not be able to "pause" a redirect and do a preflight. This has since been fixed in Gecko, but I don't know if other implementations are able to do this.

2. It would mean that we're checking "are there any registered event listeners" at a random time.

Right now the "force preflight" flag is set when a request is first initiated. From the webpage point of view this is a very well defined point in time: When .send() is called.

If we were to check for upload event listeners when the redirect from same-origin to cross-origin happens, then that results in very racy behavior from the webpage point of view. An event handler that is added after .send() may or may not cause a preflight to happen and so may or may not affect what events are fired.

	Anne (:annevk)
	Comment 8 • 10 years ago

1. I think this is already true. If you do a same-origin PUT request and you get a 307 redirect to a cross-origin URL, that should work.

2. The preflight flag would still be set at a deterministic point (although it is unfortunate we make listeners observable). Namely when you invoke send().

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 9 • 10 years ago

(In reply to Anne (:annevk) from comment #8)
> 1. I think this is already true. If you do a same-origin PUT request and you
> get a 307 redirect to a cross-origin URL, that should work.

Mind verifying that first sentence? Has anyone implemented that?

> 2. The preflight flag would still be set at a deterministic point (although
> it is unfortunate we make listeners observable). Namely when you invoke
> send().

So if an event listener is added after send(), we'll send upload events as long as the request is same-origin, and then stop doing upload events as soon as there's a redirect to cross origin?

	Anne (:annevk)
	Comment 10 • 10 years ago

http://dump.testsuite.org/xhr/cross-origin-upload-redirect.html seems to work in Chrome. (Just follow along in the network tab of the inspector.)

http://dump.testsuite.org/xhr/cross-origin-upload-redirect-late-listeners.html seems to suggest Chrome simply does not dispatch events on .upload if there's no listeners before send().