When a header name possesses multiple values, those values will be concatenated as a single, comma-delimited string value. This means that
Headers.get will always return a string or a
null value. This applies to all header names except for
Set-Cookie, which requires
Headers.getAll. This is documented below in .
let headers = new Headers();headers.get('x-foo'); //=> nullheaders.set('x-foo', '123');headers.get('x-foo'); //=> "123"headers.set('x-foo', 'hello');headers.get('x-foo'); //=> "hello"headers.append('x-foo', 'world');headers.get('x-foo'); //=> "hello, world"
Despite the fact that the
Headers.getAllmethod has been made obsolete, Cloudflare still offers this method but only for use with the
Set-Cookieheader more difficult. Any attempts to use
Headers.getAllwith other header names will throw an error. A brief history
Headers.getAllis available in this .
In Cloudflare Workers, the
Headers.getmethod returns a instead of a , which is specified by the spec. For most scenarios, this should have no noticeable effect. To compare the differences between these two string classes, refer to this .
In same-zone Worker subrequests, the value of
CF-Connecting-IP reflects the value of
x-real-ip (the client’s IP).
x-real-ip can be altered by the user in their Worker script.
In cross-zone subrequests from one Cloudflare customer zone to another Cloudflare customer zone, the
CF-Connecting-IP value will be set to the Worker client IP address
'2a06:98c0:3600::103' for security reasons.
For Worker subrequests destined for a non-Cloudflare customer zone, the
x-real-ip headers will both reflect the client’s IP address, with only the
x-real-ip header able to be altered.
When no Worker subrequest is triggered,
cf-connecting-ip reflects the client’s IP address and the
x-real-ip header is stripped.
Added to all Worker subrequests sent via
fetch(). Set to the name of the zone which owns the Worker making the subrequest. For example, a Worker script on route for
example.com will have all subrequests with the header:
The intended purpose of this header is to provide a means for recipients (for example, origins, load balancers, other Workers) to recognize, filter, and route traffic generated by Workers on specific zones.