Bug 184627 - TAO not working when multiple "Timing-Allow-Origin: *" headers are present in the HTTP header
Summary: TAO not working when multiple "Timing-Allow-Origin: *" headers are present in...
Status: RESOLVED DUPLICATE of bug 226678
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: Safari 11
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 190338
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-13 22:01 PDT by Utkarsh Goel
Modified: 2023-05-03 08:10 PDT (History)
10 users (show)

See Also:


Attachments
Patch (1.77 KB, patch)
2018-04-15 14:01 PDT, Yoav Weiss
ews-watchlist: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews102 for mac-sierra (2.21 MB, application/zip)
2018-04-15 15:07 PDT, EWS Watchlist
no flags Details
Archive of layout-test-results from ews125 for ios-simulator-wk2 (2.17 MB, application/zip)
2018-04-15 15:31 PDT, EWS Watchlist
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Utkarsh Goel 2018-04-13 22:01:08 PDT
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
Comment 1 Yoav Weiss 2018-04-15 14:01:28 PDT
Created attachment 337975 [details]
Patch
Comment 2 EWS Watchlist 2018-04-15 14:04:09 PDT
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.
Comment 3 EWS Watchlist 2018-04-15 15:07:28 PDT
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
Comment 4 EWS Watchlist 2018-04-15 15:07:29 PDT
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
Comment 5 EWS Watchlist 2018-04-15 15:31:53 PDT
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
Comment 6 EWS Watchlist 2018-04-15 15:31:54 PDT
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
Comment 7 Alex Christensen 2018-04-16 08:30:43 PDT
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.
Comment 8 Yoav Weiss 2018-04-16 08:36:23 PDT
(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
Comment 9 Yoav Weiss 2018-09-22 23:14:36 PDT
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.
Comment 10 Yoav Weiss 2018-09-23 22:53:12 PDT
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.
Comment 11 Anne van Kesteren 2023-05-03 08:10:36 PDT
This was fixed in bug 226678.

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