26906 2014-09-25 21:28:31 +0000 Request.referrer's serialization undefined when internal request's value is 'client' 2014-10-28 15:55:45 +0000 1 1 1 Unclassified WHATWG Fetch unspecified PC Linux RESOLVED FIXED P2 normal Unsorted 1 nsm.nikhil annevk mike mkwst sideshowbarker+fetchspec oldest_to_newest 112197 0 nsm.nikhil 2014-09-25 21:28:31 +0000 var r = new Request(...); // Set's internal request's referrer to client by default. r.referrer = ? Currently it resolves to the empty string since the request's internal URL is an empty string, but that seems like an implementation detail and the specific case should be defined in the spec. 112239 1 annevk 2014-09-26 08:28:16 +0000 So it seems /client/ is what we want, so that when the fetch is done, we take the policy into account as it stands at that point. It might be somewhat weird that request's referrer returns the empty string in that case, and not when you get it in a FetchEvent in a service worker, but perhaps that is fine. 112246 2 annevk 2014-09-26 13:35:03 +0000 Normalizing to the empty string seems somewhat confusing, since you might think the referrer will be omitted but it won't. Alternatives: A) We set it directly to the URL associated with the global. Then when it passes through fetch it will get normalized. B) Like A) but we normalize it directly too. (And then when fetch happens it might get normalized again.) C) We serialize a special value "about:client", that indicates this is done later. 112247 3 annevk 2014-09-26 13:35:25 +0000 Or D) of course, we just serialize to the empty string and don't consider it super problematic. 113027 4 annevk 2014-10-13 15:29:04 +0000 I think this has to be C or D, leaning towards C since it's rather trivial either way. 113837 5 annevk 2014-10-28 15:55:45 +0000 https://github.com/whatwg/fetch/commit/30c35ec10994d0005f45879778424e8fc7272bde