New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 724452 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Leaves the project on 2018/03/02
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

[CORS] Reject an Access-Control-Expose-Headers header that doesn't conform to the ABNF

Project Member Reported by annevank...@gmail.com, May 19 2017

Issue description

Test: https://github.com/w3c/web-platform-tests/pull/6000.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1364598 it was discovered that only Firefox handles this correctly out of the four browser engines. We'd appreciate if you could fix this. If you don't feel like you could fix this, please propose a change to the Fetch standard (and what change you'd like that to be) instead.
 
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)
Summary: [CORS] Reject an Access-Control-Expose-Headers header that doesn't conform to the ABNF (was: Access-Control-Expose-Headers parsed incorrectly)
ParseAccessControlExposeHeadersAllowList() must be fixed to validate the input against the ABNF.

https://fetch.spec.whatwg.org/#http-new-header-syntax
Owner: tyoshino@chromium.org
Status: Started (was: Available)
yhirano@ found a spec issue during code review. Filed as https://github.com/whatwg/fetch/issues/548
Project Member

Comment 6 by bugdroid1@chromium.org, May 25 2017

Status: Fixed (was: Started)

Sign in to add a comment