-
Notifications
You must be signed in to change notification settings - Fork 8
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
Does any of this require CORS-with-forced-preflight? #10
Comments
I overlooked this ticked, sorry. |
What should we do when mode is no CORS? Failing the operation seems reasonable to me. |
Failing sounds fine, yes. There's no need to set mode btw if we don't want to change it, I would only create branches for the cases where we anticipate a change. |
Created a change: https://github.com/yutakahirano/fetch-with-streams/tree/28271acbfaaf1fd2f2ad4f19c8f3cf143298b90a |
@annevk ping |
Sorry. Request class modifications look okay. Independent security review is also required but I guess that'll happen as part of landing the code in browsers. |
Thanks, merged. |
Reopen this issue because WritableStream is dropped from the draft on b32685d. I will fix it again in the future. |
It sounds like this means uploading a request body would require a forced preflight? |
That is the question. There's two parts to this. 1) Due to us using streams, you can discover much more about the server than if you transmit a single Curious to see what @dveditz, @mikewest et al think. Obviously not doing a preflight would be much more desirable. (On the other hand, if we get origin-wide preflights it might not be that big of a deal.) |
Erring on the side of caution seems reasonable; I haven't looked at the spec, but based on the comment above (#10 (comment)), it seems like the right balance. (I agree, by the way, that giving servers the ability to opt-into certain kinds of preflightless requests on an origin-wide basis makes it less painful to require them for new features. That tips the balance further towards conservationism...) |
Basic tests: web-platform-tests/wpt#4362. More tests are expected to be written as part of the implementation effort. Fixes #88, fixes yutakahirano/fetch-with-streams#10, fixes yutakahirano/fetch-with-streams#57, and fixes yutakahirano/fetch-with-streams#66.
Since this allows inspection of how fast a body is transmitted to the server, should this require a preflight just like we do in XMLHttpRequest for progress events?
The text was updated successfully, but these errors were encountered: