This repository has been archived by the owner on Feb 7, 2023. It is now read-only.
RequestInit and Request cf properties are different #15
Milestone
Comments
|
I just ran in to this as well! |
|
I'll take a shot at reconciling these this week. |
ispivey
added a commit
to ispivey/workers-types
that referenced
this issue
May 10, 2020
Fixes cloudflare#15. There are two distinct cf objects serves associated with a Request: 1. On an eyeball Request attached to a FetchEvent, the cf property contains metadata about the request, provided by Cloudflare's edge. 2. As part of a dictionary of configuration passed to the Request constructor, the cf property allows a user to control certain Cloudflare functionality that can be applied to said Request, like image resizing. While those two things are both objects in a dictionary with the key "cf", they are otherwise distinct. This change makes these two types explicitly different, and specifies that a Request constructor's RequestInit dict can have a "cf" property that is either (1) or (2). Previously, passing a Request object as the `init` arg to the Request constructor failed, because an eyeball request's cf prop did not have the same shape as (2).
ispivey
added a commit
to ispivey/workers-types
that referenced
this issue
May 10, 2020
Fixes cloudflare#15. There are two distinct cf objects serves associated with a Request: 1. On an eyeball Request attached to a FetchEvent, the cf property contains metadata about the request, provided by Cloudflare's edge. 2. As part of a dictionary of configuration passed to the Request constructor, the cf property allows a user to control certain Cloudflare functionality that can be applied to said Request, like image resizing. While those two things are both objects in a dictionary with the key "cf", they are otherwise distinct. This change makes these two types explicitly different, and specifies that a Request constructor's RequestInit dict can have a "cf" property that is either (1) or (2). Previously, passing a Request object as the `init` arg to the Request constructor failed, because an eyeball request's cf prop did not have the same shape as (2).
ispivey
added a commit
that referenced
this issue
May 14, 2020
Fixes #15. There are two distinct cf objects serves associated with a Request: 1. On an eyeball Request attached to a FetchEvent, the cf property contains metadata about the request, provided by Cloudflare's edge. 2. As part of a dictionary of configuration passed to the Request constructor, the cf property allows a user to control certain Cloudflare functionality that can be applied to said Request, like image resizing. While those two things are both objects in a dictionary with the key "cf", they are otherwise distinct. This change makes these two types explicitly different, and specifies that a Request constructor's RequestInit dict can have a "cf" property that is either (1) or (2). Previously, passing a Request object as the `init` arg to the Request constructor failed, because an eyeball request's cf prop did not have the same shape as (2).
This was referenced May 28, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
RequestInitandRequestcf properties are different, this makes using patterns likereturn new Request(parsedUrl.toString(), request)impossible becauseRequest.cfis not structurally identical toRequestInit.cf.I suggest we converge on a common
cftype for bothRequestandRequestInitto support the above pattern.The text was updated successfully, but these errors were encountered: