Bug 185473

Summary:

Fetch: content-length header is being added to the safe-list

Product:

WebKit

Reporter:

shacharz

Component:

New Bugs

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

ap, commit-queue, dbates, ews-watchlist, Ms2ger, rbuis, rniwa, webkit-bug-importer, youennf

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none
Archive of layout-test-results from ews102 for mac-sierra	none
Archive of layout-test-results from ews104 for mac-sierra-wk2	none
Patch	none

shacharz

Reported 2018-05-09 08:09:31 PDT

Steps to reproduce the problem: 1. create a CORS fetch request to a url that has content-length in its response and doesn't add content-length to access-control-expose-headers 2. content-length should be accessible in the response's headers What is the expected behavior? When doing a CORS fetch request if content-length exists in the http response it should be exposed on the response headers even if it's not added to the access-control-expose-headers. What went wrong? content-length is not exposed see: https://github.com/whatwg/fetch/pull/626 https://github.com/w3c/web-platform-tests/pull/10930

Attachments
Patch (4.83 KB, patch) 2018-08-08 12:16 PDT, Rob Buis	no flags	Details Formatted Diff Diff
Archive of layout-test-results from ews102 for mac-sierra (2.30 MB, application/zip) 2018-08-08 13:21 PDT, EWS Watchlist	no flags	Details
Archive of layout-test-results from ews104 for mac-sierra-wk2 (2.95 MB, application/zip) 2018-08-08 13:30 PDT, EWS Watchlist	no flags	Details
Patch (6.54 KB, patch) 2018-08-08 13:31 PDT, Rob Buis	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Rob Buis

Comment 1 2018-08-08 12:16:02 PDT

Created attachment 346783 [details] Patch

EWS Watchlist

Comment 2 2018-08-08 13:21:09 PDT

Comment on attachment 346783 [details] Patch Attachment 346783 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/8801197 New failing tests: imported/w3c/web-platform-tests/fetch/api/cors/cors-filtering-worker.html

EWS Watchlist

Comment 3 2018-08-08 13:21:11 PDT

Created attachment 346786 [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 4 2018-08-08 13:30:27 PDT

Comment on attachment 346783 [details] Patch Attachment 346783 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/8801206 New failing tests: imported/w3c/web-platform-tests/fetch/api/cors/cors-filtering-worker.html

EWS Watchlist

Comment 5 2018-08-08 13:30:28 PDT

Created attachment 346787 [details] Archive of layout-test-results from ews104 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6

Rob Buis

Comment 6 2018-08-08 13:31:05 PDT

Created attachment 346788 [details] Patch

WebKit Commit Bot

Comment 7 2018-08-14 01:29:22 PDT

Comment on attachment 346788 [details] Patch Clearing flags on attachment: 346788 Committed r234840: <https://trac.webkit.org/changeset/234840>

WebKit Commit Bot

Comment 8 2018-08-14 01:29:24 PDT

All reviewed patches have been landed. Closing bug.

Radar WebKit Bug Importer

Comment 9 2018-08-14 01:30:19 PDT

<rdar://problem/43274948>

shacharz

Comment 10 2018-12-06 07:29:10 PST

Tested on Safari 12.01 and it's not exposed by default. When is it going to land ?

Rob Buis

Comment 11 2018-12-07 01:21:45 PST

Hi, (In reply to shacharz from comment #10) > Tested on Safari 12.01 and it's not exposed by default. When is it going to > land ? Assuming you use OS X, a recent Safari Technology Preview should have this fix.

Note You need to log in before you can comment on or make changes to this bug.