Would it be correct for XHR to reference "worker's API referrer source" as the referrer source for XHR requests from workers, like I tried to do here:

https://github.com/whatwg/xhr/pull/13 ?

XHR

So as far as I can tell, the solution that most simplifies the XHR spec is to change the reference to a 'document' and replace it with a reference to a 'script settings object'. That is, replace the bit in the constructor that does:

   "...to the document associated with the global object of..."

...with something like:

   "...to the _relevant settings object_ of the global object of..."

...and in the worker case, just use the "incumbent settings object" instead, in that same algorithm.

Then, replace open() steps 2 and 3 (and their substeps) with (where /foo/ is the variable you set the settings object to):

 0. If the _responsible document_ specified by /foo/ is not active...

 0. Set /base/ to the _API base URL_ specified by /foo/.

 0. Set /source origin/ to the _origin_ specified by /foo/.

 0. Set /referrer source/ to the _API referrer source_ specified by /foo/.

I think that takes care of all of this for you.


While I'm at it:

"If the JavaScript global environment is a worker environment, implementations must act as if Document and Document? in the above IDL were not exposed. I.e. send() is not overloaded with it and responseXML always returns null (as required by its definition, too)."

Why not do this as an 'implements' that only applies in non-worker environments?

Also, the "document response entity body" algorithm probably doesn't need to check the environment, since there doesn't seem to be any way to invoke it in a worker environment. (Also, I don't understand the "if it is null, let it be". Should that be "when it is set to null"? Or something? When is the algorithm run, exactly? It's not clear.)

NOTIFICATIONS

Replace "entry script's base URL" with "API base URL specified by the entry settings object".

I think that's all that needs changing.

Ian, I could not find "relevant settings object" defined. I used "script settings object" for now. Does that work?

https://github.com/whatwg/xhr/commit/aca101a2a92a1bed790c2589a04dc15a6aeb8a33


Also, under what circumstances would the API referrer source be a URL and not a Document?

Relevant settings object is what you want:

http://www.whatwg.org/specs/web-apps/current-work/#relevant-settings-object-for-a-global-object

API referrer source is a URL in workers. (Looks like this got broken in my recent edits, fixed.)

Fixed that now: https://github.com/whatwg/xhr/commit/78c244ee6e9ca55fe70fdef95355e643a2c07586

Still need to answer questions from comment 2. And fix referrer source which is a separate bug.

I will clean up the IDL when there is IDL syntax for document/worker distinction.

Until then document response entity body needs to check the environment I think.

The "if x null, set x to y" is for when x is retrieved. x is set to null during open() but cannot be retrieved until the request is completed. The idea with using this type of wording is that x will have its value cached until open() is invoked (again).

(In reply to Anne from comment #7)
> I will clean up the IDL when there is IDL syntax for document/worker
> distinction.

Ok.


> Until then document response entity body needs to check the environment I
> think.

As far as I can tell, the current text can never be triggered.


> The "if x null, set x to y" is for when x is retrieved. x is set to null
> during open() but cannot be retrieved until the request is completed. The
> idea with using this type of wording is that x will have its value cached
> until open() is invoked (again).

Personally I don't understand what it means, normatively. Either something has a value in which case retrieving it gives you that value, or, something has a getter, in which case retrieving it runs the algorithm and returns a value, but it doesn't itself have a value per se. I don't understand the concept of something both having a value and having an algorithm run when you call its getter.

(In reply to Ian 'Hixie' Hickson from comment #8)
> (In reply to Anne from comment #7)
> > I will clean up the IDL when there is IDL syntax for document/worker
> > distinction.
> 
> Ok.
> 
> 
> > Until then document response entity body needs to check the environment I
> > think.
> 
> As far as I can tell, the current text can never be triggered.
> 

Setting xhr.responseType to "document" in a worker environment is simply ignored and the value remains default, empty string. Hence, neither xhr.response nor xhr.responseText does get through to "document response entity body" algorithm. However, xhr.responseXML does do as it allows xhr.responseType to be empty string though it finally returns null anyway. (Both Chrome and Firefox return null with xhr.responseXML as specified; oddly, Chrome still returns null with xhr.response whereas Firefox returns the text response body.)

If the intention is to disallow the "document" responseType in a worker context at all, it seems safe to remove the environment checking condition in the "document response entity body" algorithm. However, I wonder if there's any reason "document" responseType should be disallowed in worker context. IMO, it seems plausible to fetch a document in a worker context and post it to the main document that created the worker?

> 
> > The "if x null, set x to y" is for when x is retrieved. x is set to null
> > during open() but cannot be retrieved until the request is completed. The
> > idea with using this type of wording is that x will have its value cached
> > until open() is invoked (again).
> 
> Personally I don't understand what it means, normatively. Either something
> has a value in which case retrieving it gives you that value, or, something
> has a getter, in which case retrieving it runs the algorithm and returns a
> value, but it doesn't itself have a value per se. I don't understand the
> concept of something both having a value and having an algorithm run when
> you call its getter.

Reopening per comment 8 to phrase the requirements a bit differently.

(In reply to Jungkee Song from comment #9)
> However, xhr.responseXML does do

Ah, I see. I interpreted "If the JavaScript global environment is a worker environment, implementations must act as if Document and Document? in the above IDL were not exposed" as meaning that the relevant attributes just weren't present in workers, not that they were useless.

Finally fixed comment 8!

https://github.com/whatwg/xhr/commit/848b22e99f36cb4a4481b77c382a1fd484ddf737