Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow range header without preflight #1312

Merged
merged 15 commits into from
Oct 5, 2021
Merged

Conversation

jakearchibald
Copy link
Collaborator

@jakearchibald jakearchibald commented Sep 28, 2021

Fixes #1310.


Preview | Diff

fetch.bs Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Sep 28, 2021

Can we consolidate with https://wicg.github.io/background-fetch/#extract-content-range-values-algorithm perhaps? (I realize there are delimiter differences, but perhaps they can be abstracted somehow. See also WICG/background-fetch#157.)

The other thing that might help is to use isomorphic decode, so you can operate on a string. That removes the need for state and allows for using Infra's "collect a sequence" algorithms.

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Show resolved Hide resolved
@jakearchibald
Copy link
Collaborator Author

jakearchibald commented Sep 28, 2021

@annevk I'm not sure how useful it is to consolidate with Content-Range, since the format is pretty different.

  • ^bytes \d+-\d+/(\*|\d+)$ - simple Content-Range
  • ^bytes=\d+-\d*$ - simple Range

I think it'd be confusing to try and combine the two.

I'll look at defining this using "collect a sequence", or would you rather I used the ABNF style from background-fetch?

@annevk
Copy link
Member

annevk commented Sep 28, 2021

Fair about combining. They are a bit more different than I thought. Implementers (at least Matt Menke) seem to prefer algorithms over ABNF and that's also the style I've used for the other header parsers thus far so I guess we should stick with that. Also, ABNF often leads to implementations that approximate the parser requirements in my experience.

@jakearchibald
Copy link
Collaborator Author

@annevk cool, I've rewritten it using "collecting a sequence of code points", it's much easier to read now.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks very readable indeed.

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
@jakearchibald
Copy link
Collaborator Author

Ugh, I just realised it's bytes= rather than bytes . It's Content-Range that uses bytes . I've fixed up the range-setting algorithm too, but I'm happy to make that a different PR.

@jakearchibald
Copy link
Collaborator Author

jakearchibald commented Sep 28, 2021

This PR aims to allow, without requiring a preflight, CORS requests with a Range header similar to those the browser would send when downloading media or a resumable download.

When requesting media, browsers will typically request ranges like bytes=123456-789012, to target things like metadata in the resource, and bytes=0- for the initial media download.

When resuming the download of files, browsers will typically just use the initial range, like bytes=123-.

However, there are a few novel requests that this PR enables:

  • Ranges outside the length of the resource. This includes cases where the server cannot determine the resources content length (eg it's still being created).
  • Tiny ranges, eg bytes=123-123. I don't think browsers do this.
  • Range along with a POST request. Downloads can be initiated via a POST request, but browsers will not send a Range header in these cases.
  • Range and Origin headers on a GET request. We already include Origin with POST requests, but not GET unless it's a CORS request.
  • Combining Range with unusual values in other safe-listed headers, such as accept: whatever.

Only "ranges outside the length of the resource" makes me raise an eyebrow, so I'd like a second opinion on that.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the analysis! Modulo some final nits this looks good to me now. I wonder if @mikewest, @yutakahirano, and @youennf can help out with additional security review.

(This also ends up fixing #1265 now. It seems okay to include the fix for that here, as long as we indicate it in the final commit message.)

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
jakearchibald and others added 3 commits September 29, 2021 08:50
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
@jakearchibald
Copy link
Collaborator Author

(This also ends up fixing #1265 now. It seems okay to include the fix for that here, as long as we indicate it in the final commit message.)

Ah, sorry I missed that original issue.

Copy link
Member

@yutakahirano yutakahirano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jakearchibald
Copy link
Collaborator Author

@rayankans over to you for the tests

@rayankans
Copy link

I created a PR for the tests here: web-platform-tests/wpt#31058

@annevk
Copy link
Member

annevk commented Oct 4, 2021

I'm comfortable with merging this once we have implementation bugs.

@jakearchibald
Copy link
Collaborator Author

jakearchibald commented Oct 4, 2021

Implementation bugs added.

Commit message:


Allow particular Range header values without a preflight.

The allowed format aligns with the values the browser uses when requesting media and resuming downloads.
Spec discussion: #1310
Spec PR: #1312
Tests PR: web-platform-tests/wpt#31058

annevk pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 5, 2021
For whatwg/fetch#1312.

Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
@annevk annevk merged commit 6f37b51 into main Oct 5, 2021
@annevk annevk deleted the allow-range-header-without-preflight branch October 5, 2021 16:02
@annevk
Copy link
Member

annevk commented Oct 5, 2021

Thanks all!

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Oct 6, 2021
…eaders from preflight, a=testonly

Automatic update from web-platform-tests
Fetch: tests for safelisting simple range headers from preflight

For whatwg/fetch#1312.

Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
--

wpt-commits: 902e9dceb10d98a646ad77d46df62e0365626fff
wpt-pr: 31058
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Oct 7, 2021
…eaders from preflight, a=testonly

Automatic update from web-platform-tests
Fetch: tests for safelisting simple range headers from preflight

For whatwg/fetch#1312.

Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
--

wpt-commits: 902e9dceb10d98a646ad77d46df62e0365626fff
wpt-pr: 31058
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this pull request Oct 11, 2021
The Fetch standard now safelists 'simple' range headers from
preflight checks. (whatwg/fetch#1312)

This CL also successfully runs against the new WPT suite
(web-platform-tests/wpt#31058)

I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/0f1zQ4hjoyQ

Bug: 1255711

Change-Id: I06ee27fec586950b7d45e3cba416df1b5090fa4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3190330
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Rayan Kanso <rayankans@chromium.org>
Cr-Commit-Position: refs/heads/main@{#930108}
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this pull request Nov 18, 2021
For whatwg/fetch#1312.

Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this pull request Oct 14, 2022
The Fetch standard now safelists 'simple' range headers from
preflight checks. (whatwg/fetch#1312)

This CL also successfully runs against the new WPT suite
(web-platform-tests/wpt#31058)

I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/0f1zQ4hjoyQ

Bug: 1255711

Change-Id: I06ee27fec586950b7d45e3cba416df1b5090fa4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3190330
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Rayan Kanso <rayankans@chromium.org>
Cr-Commit-Position: refs/heads/main@{#930108}
NOKEYCHECK=True
GitOrigin-RevId: 7b4dbc8d73cd09187b1501931141871f9d90b30d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Add range to CORS-safelisted request-headers
4 participants