Bug 272682
| Summary: | Timing-Allow-Origin works with 302 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | jannis.rautenstrauch |
| Component: | Page Loading | Assignee: | youenn fablet <youennf> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | beidson, karlcow, webkit-bug-importer |
| Priority: | P2 | Keywords: | BrowserCompat, InRadar |
| Version: | Safari 17 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
jannis.rautenstrauch
If a response with status code 302 sets a timing-allow-origin header, WebKit grants reading access (same as for status code 200).
Firefox and Chromium do not apply the timing-allow-origin header on a 302 response.
I am not sure if the specifications say anything about this edge case. As the other two implementations agree, I filed the bug here.
Example URL: https://sub.headers.websec.saarland/_hp/tests/perfAPI-tao.sub.html?resp_type=basic&browser_id=1&label=TAO&first_id=217&last_id=217&scheme=https&t_resp_id=217&t_element_relation=img_direct&t_resp_origin=https://headers.webappsec.eu
- Response with status code 302 sets 'timing-allow-origin: *'
- "requestStart != 0": true in WebKit
- "requestStart != 0": false in Firefox, Chromium
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/126531139>
youenn fablet
Pull request: https://github.com/WebKit/WebKit/pull/27377
EWS
Committed 278448@main (6a2c5a304253): <https://commits.webkit.org/278448@main>
Reviewed commits have been landed. Closing PR #27377 and removing active labels.