Bug 184627 – TAO not working when multiple "Timing-Allow-Origin: *" headers are present in the HTTP header

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKit API

[Utkarsh Goel]

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36



Steps to reproduce the problem:
1. Visit http://dev.utkarshgoel.in/index_nonminify.html and monitor the network activity in the devTools. 

This page downloads resources from three origins: dev.utkarshgoel.in, dev1.utkarshgoel, and dev2.utkarshgoel.in. Resources downloaded from all three origins have the "Timing-Allow-Origin: *" HTTP header present. 

In my testcase, I made the server add multiple "Timing-Allow-origin: *" headers for the origin  "dev2.utkarshgoel.in".

2. Observe the network activity as the page loads to identify the resource downloaded from the origin "dev2.utkarshgoel.in". The resource should be http://dev2.utkarshgoel.in/docs/utkarsh-goel-resume.pdf and should have two occurrences of the header "Timing-Allow-Origin: *".

Next, type in the console: 
performance.getEntries("resource") 

to check the value of "domainLookupStart" for this resource. This value will be 0, even when the "Timing-Allow-Origin: *" header was present for this resource's HTTP header.


3. Next, observe the network activity to identify the resource downloaded form the origin "dev1.utkarshgoel.in". This resource should be http://dev1.utkarshgoel.in/misc.html and has only one occurrence of the "Timing-Allow-Origin: *" header

In the console, type:

performance.getEntries("resource")

and find this resource's "domainLookupStart" value. This value will be greater than 0. This indicates that the Timing-Allow-Origin worked as expected for the origin dev1.utkarshgoel.in, allowing the origin "dev.utkarshgoel.in" to access the timing information for the resource from "dev1.utkarshgoel.in".



What is the expected behavior?
The browser should have made available the timing information for the resource downloaded from the origin "dev2.utkarshgoel.in" because it had the "Timing-Allow-Origin: *" present in the HTTP header



What went wrong?
Since the browser received multiple "Timing-Allow-Origin: *" headers, it concatenated the values present on all the "Timing-Allow-Origin" header, which resulted in the final value of "*, *". This value neither matched the origin name "dev.utkarshgoel.in" nor it matched the wildcard hostname "*". 

Did this work before? No 

Does this work in other browsers? No
 The same bug also applies to Chromium. I have filed the same bug there at https://bugs.chromium.org/p/chromium/issues/detail?id=833032

This bug is related to the Resource timing API

[Yoav Weiss]

Created attachment 337975 [details]
Patch

[EWS Watchlist]

Attachment 337975 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:8:  You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible.  [changelog/nonewtests] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[EWS Watchlist]

Comment on attachment 337975 [details]
Patch

Attachment 337975 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/7325145

New failing tests:
animations/needs-layout.html

[EWS Watchlist]

Created attachment 337980 [details]
Archive of layout-test-results from ews102 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-sierra  Platform: Mac OS X 10.12.6

[EWS Watchlist]

Comment on attachment 337975 [details]
Patch

Attachment 337975 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/7325170

New failing tests:
legacy-animation-engine/css3/filters/backdrop/animation.html

[EWS Watchlist]

Created attachment 337981 [details]
Archive of layout-test-results from ews125 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews125  Port: ios-simulator-wk2  Platform: Mac OS X 10.13.4

[Alex Christensen]

Comment on attachment 337975 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=337975&action=review

> Source/WebCore/ChangeLog:8
> +        No new tests (OOPS!).

This should have a test.

[Yoav Weiss]

(In reply to Alex Christensen from comment #7)
> Comment on attachment 337975 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=337975&action=review
> 
> > Source/WebCore/ChangeLog:8
> > +        No new tests (OOPS!).
> 
> This should have a test.

Of course (which is why I haven't "r?" this just yet). Tests for this are already part of WPT[1], but for some reason don't run properly (and have unrelated expectations as a result).
I need to figure out why they fail to run ATM and fix that.

[1] https://github.com/w3c/web-platform-tests/blob/master/resource-timing/resources/iframe_TAO_match_wildcard.html

[Yoav Weiss]

Seems like the current tests pass because XHR RT entries from the current tests are not included in the performance timeline :/

I'll change the tests to fail in such a case.

[Yoav Weiss]

I'm importing WPTs for this at: https://bugs.webkit.org/show_bug.cgi?id=189903

Once that lands, I'll rebase and change their expectations.

[Anne van Kesteren]

This was fixed in bug 226678.

*** This bug has been marked as a duplicate of bug 226678 ***