recursal/MDN huggingface dataset:
Headers: get() method
=====================

 The **`get()`** method of the `Headers` interface
 returns a byte string of all the values of a header within a `Headers` object
 with a given name. If the requested header doesn't exist in the `Headers`
 object, it returns `null`.

 For security reasons, some headers can only be controlled by the user agent. These
 headers include the forbidden header names
 and forbidden response header names.

**Note:** This feature is available in Web Workers

Syntax
------


```js
get(name)
```

### Parameters

`name`

 The name of the HTTP header whose values you want to retrieve from the
 `Headers` object. If the given name is not the name of an HTTP header, this
 method throws a `TypeError`. The name is case-insensitive.


### Return value

 A `String` sequence representing the values of the retrieved header or
 `null` if this header is not set.

Examples
--------

Creating an empty `Headers` object is simple:


```js
const myHeaders = new Headers(); // Currently empty
myHeaders.get("Not-Set"); // Returns null
```


 You could add a header to this using `Headers.append`, then retrieve it
 using `get()`:


```js
myHeaders.append("Content-Type", "image/jpeg");
myHeaders.get("Content-Type"); // Returns "image/jpeg"
```


 If the header has multiple values associated with it, the byte string will contain all
 the values, in the order they were added to the Headers object:


```js
myHeaders.append("Accept-Encoding", "deflate");
myHeaders.append("Accept-Encoding", "gzip");
myHeaders.get("Accept-Encoding"); // Returns "deflate, gzip"
myHeaders
  .get("Accept-Encoding")
  .split(",")
  .map((v) => v.trimStart()); // Returns [ "deflate", "gzip" ]
```

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # ref-for-dom-headers-get① |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* ServiceWorker API
* HTTP access control (CORS)
* HTTP
Headers: keys() method
======================

 The **`Headers.keys()`** method returns an
 `iterator` allowing to go through all keys contained
 in this object. The keys are `String` objects.

**Note:** This feature is available in Web Workers

Syntax
------


```js
keys()
```

### Parameters

None.

### Return value

Returns an `iterator`.

Examples
--------


```js
// Create a test Headers object
const myHeaders = new Headers();
myHeaders.append("Content-Type", "text/xml");
myHeaders.append("Vary", "Accept-Language");

// Display the keys
for (const key of myHeaders.keys()) {
  console.log(key);
}
```


The result is:
```

content-type
vary
```

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* ServiceWorker API
* HTTP access control (CORS)
* HTTP
Headers: set() method
=====================

 The **`set()`** method of the `Headers` interface
 sets a new value for an existing header inside a `Headers` object, or adds
 the header if it does not already exist.

 The difference between `set()` and `Headers.append` is that if
 the specified header already exists and accepts multiple values, `set()`
 overwrites the existing value with the new one, whereas `Headers.append`
 appends the new value to the end of the set of values.

 For security reasons, some headers can only be controlled by the user agent. These
 headers include the forbidden header names
 and forbidden response header names.

**Note:** This feature is available in Web Workers

Syntax
------


```js
set(name, value)
```

### Parameters

`name`

 The name of the HTTP header you want to set to a new value. If the given name is not
 the name of an HTTP header, this method throws a `TypeError`.


`value`

The new value you want to set.

### Return value

None (`undefined`).

Examples
--------

Creating an empty `Headers` object is simple:


```js
const myHeaders = new Headers(); // Currently empty
```


 You could add a header to this using `Headers.append`, then set a new
 value for this header using `set()`:


```js
myHeaders.append("Content-Type", "image/jpeg");
myHeaders.set("Content-Type", "text/html");
```


 If the specified header does not already exist, `set()` will create it and
 set its value to the specified value. If the specified header does already exist and
 does accept multiple values, `set()` will overwrite the existing value with
 the new one:


```js
myHeaders.set("Accept-Encoding", "deflate");
myHeaders.set("Accept-Encoding", "gzip");
myHeaders.get("Accept-Encoding"); // Returns 'gzip'
```


 You'd need `Headers.append` to append the new value onto the values, not
 overwrite it.

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # ref-for-dom-headers-set① |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* ServiceWorker API
* HTTP access control (CORS)
* HTTP
Headers: getSetCookie() method
==============================

The **`getSetCookie()`** method of the `Headers` interface returns an array containing the values of all `Set-Cookie` headers associated with a response. This allows `Headers` objects to handle having multiple `Set-Cookie` headers, which wasn't possible prior to its implementation.

This method is intended for use on server environments (for example Node.js). Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a forbidden response-header name that must be filtered out from any response exposed to frontend code.

**Note:** This feature is available in Web Workers

Syntax
------


```js
getSetCookie()
```

### Parameters

None.

### Return value

An array of strings representing the values of all the different `Set-Cookie` headers associated with a response.

If no `Set-Cookie` headers are set, the method will return an empty array (`[ ]`).

Examples
--------

As alluded to above, running code like the following on the client won't return any results — `Set-Cookie` is filtered out from `Headers` retrieved over the network.


```js
fetch("https://example.com").then((response) => {
  console.log(response.headers.getSetCookie());
  // No header values returned
});
```


However, the following could be used to query multiple `Set-Cookie` values. This is much more useful on the server, but it would also work on the client.


```js
const headers = new Headers({
  "Set-Cookie": "name1=value1",
});

headers.append("Set-Cookie", "name2=value2");

headers.getSetCookie();
// Returns ["name1=value1", "name2=value2"]
```

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # dom-headers-getsetcookie |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTTP
* `Set-Cookie`
Headers: forEach() method
=========================

The **`Headers.forEach()`** method executes a callback function once per each key/value pair in the `Headers` object.

**Note:** This feature is available in Web Workers

Syntax
------


```js
forEach(callbackFn)
forEach(callbackFn, thisArg)
```

### Parameters

`callbackFn`

Function to execute for each entry in the map. It takes the following arguments:

`value`

Value of the currently visited header entry.

`key`

Name of the currently visited header entry.

`object`

The Headers object being iterated.


`thisArg` Optional

Value to use as `this` when executing `callback`.

### Return value

`undefined`.

Description
-----------

The `Headers.forEach()` method executes the provided callback once for each key of the Headers which actually exist. It is not invoked for keys which have been deleted. However, it is executed for keys which are present but have the value undefined.

Examples
--------

### Printing the contents of Headers object

The following code logs a line for each key/value in the `myHeaders` object.


```js
// Create a new test Headers object
const myHeaders = new Headers();
myHeaders.append("Content-Type", "application/json");
myHeaders.append("Cookie", "This is a demo cookie");
myHeaders.append("compression", "gzip");

// Display the key/value pairs
myHeaders.forEach((value, key) => {
  console.log(`${key} ==> ${value}`);
});
```


The result is:
```

compression ==> gzip
content-type ==> application/json
cookie ==> This is a demo cookie
```

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Map.prototype.forEach()`
* ServiceWorker API
* HTTP access control (CORS)
* HTTP
Headers: append() method
========================

 The **`append()`** method of the `Headers`
 interface appends a new value onto an existing header inside a `Headers`
 object, or adds the header if it does not already exist.

 The difference between `set()` and `append()` is
 that if the specified header already exists and accepts multiple values,
 `set()` will overwrite the existing value with the new one, whereas
 `append()` will append the new value onto the end of the set of values.

 For security reasons, some headers can only be controlled by the user agent. These
 headers include the forbidden header names
 and forbidden response header names.

**Note:** This feature is available in Web Workers

Syntax
------


```js
append(name, value)
```

### Parameters

`name`

The name of the HTTP header you want to add to the `Headers` object.

`value`

The value of the HTTP header you want to add.

### Return value

None (`undefined`).

Examples
--------

Creating an empty `Headers` object is simple:


```js
const myHeaders = new Headers(); // Currently empty
```


You could add a header to this using `append()`:


```js
myHeaders.append("Content-Type", "image/jpeg");
myHeaders.get("Content-Type"); // Returns 'image/jpeg'
```


 If the specified header already exists, `append()` will change its value to
 the specified value. If the specified header already exists and accepts multiple values,
 `append()` will append the new value to the end of the value set:


```js
myHeaders.append("Accept-Encoding", "deflate");
myHeaders.append("Accept-Encoding", "gzip");
myHeaders.get("Accept-Encoding"); // Returns 'deflate, gzip'
```


To overwrite the old value with a new one, use `Headers.set`.

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # ref-for-dom-headers-append① |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* ServiceWorker API
* HTTP access control (CORS)
* HTTP
Headers: values() method
========================

 The **`Headers.values()`** method returns an
 `iterator` allowing to go through all values contained
 in this object. The values are `String` objects.

**Note:** This feature is available in Web Workers

Syntax
------


```js
values()
```

### Parameters

None.

### Return value

Returns an `iterator`.

Examples
--------


```js
// Create a test Headers object
const myHeaders = new Headers();
myHeaders.append("Content-Type", "text/xml");
myHeaders.append("Vary", "Accept-Language");

// Display the values
for (const value of myHeaders.values()) {
  console.log(value);
}
```


The result is:
```

text/xml
Accept-Language
```

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* ServiceWorker API
* HTTP access control (CORS)
* HTTP
RTCIceCandidate: foundation property
====================================

 The **`RTCIceCandidate`**
 interface's read-only **`foundation`** property is a string
 which uniquely identifies the candidate across multiple transports.

 The `foundation` can therefore be used to correlate candidates that are present on
 multiple `RTCIceTransport` objects

Value
-----

 A string which uniquely identifies the candidate across all
 `RTCIceTransport`s on which it is available.


**Note:** If `port` is `null` — and
 `port` is supported by the user agent — passing the
 candidate to `addIceCandidate()`
 will fail, throwing an `OperationError` exception.


Usage notes
-----------

 Consider this SDP attribute line (a-line) which describes an ICE
 candidate:
```

a=candidate:4234997325 1 udp 2043278322 192.0.2.172 44323 typ host
```


The field `"4234997325"` is the foundation.

Examples
--------

 This code snippet uses the `foundation` of two candidates to determine if
 they're actually the same candidate.


```js
if (candidate1.foundation === candidate2.foundation) {
  /\* the two candidates are the same, even if they're on
 different transports \*/
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-foundation |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
RTCIceCandidate: relatedPort property
=====================================

The **`RTCIceCandidate`** interface's read-only **`relatedPort`** property indicates the port number of reflexive or relay candidates.

If the candidate is a host candidate (that is, its `address` is in fact the real IP address of the remote peer), `relatedPort` is `null`.

 The `relatedPort` field's value is set from the `candidateInfo` options object passed to the `RTCIceCandidate()` constructor.
 You can't specify the value of `relatedPort` directly in the options object, but its value is automatically extracted from the object's `candidate` a-line, if it's formatted properly (the `rel-port` field).

 The related address (`relatedAddress`) and port are not used at all by ICE itself; they are provided for
 analysis and diagnostic purposes only, and their inclusion may be blocked by security systems, so do not rely on them having non-`null` values.

Value
-----

 An unsigned 16-bit value containing the candidate's related port number, if any. For
 both peer and server reflexive candidates, the related address and port describe the
 base for that candidate. For relay candidates, the related address and port provide the
 mapped address selected by the TURN server.

For host candidates, `relatedPort` is `null`, meaning the field is not included in the candidate's a-line.

Usage notes
-----------

 The related address and port are not used by ICE itself, and are only present for
 diagnostic and Quality-of-Service purposes. They may in fact be omitted for security
 reasons, but if present can be a useful tool during debugging. See the Example, which shows a bit of this.

 Here's an SDP attribute line (a-line) describing an ICE candidate
 discovered by the STUN server:
```

a=candidate:4234997325 1 udp 2043278322 192.0.2.172 6502 typ srflx raddr 198.51.100.45 rport 32768 generation 0
```


The remote port, `relatedPort`, is the number immediately following the `"rport"` label on the a-line, or 32768.

Examples
--------

 In this example, the candidate's `type` is
 checked, and then debugging output is presented, based on the candidate type, including
 the candidate's type, address (`ip` and `port`), and related address (`relatedAddress` and `relatedPort`).


```js
const ip = candidate.ip;
const port = candidate.port;
const relIP = candidate.relatedAddress;
const relPort = candidate.relatedPort;

if (relIP && relPort) {
  console.log(
    `Candidate type '${type}' — contact address: ${ip} ${port}, related address: ${relIP} ${relPort}`,
  );
} else {
  console.log(`Host candidate address is ${ip} ${port}`);
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-relatedport |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC API
* Introduction to WebRTC protocols
* WebRTC connectivity
* Lifetime of a WebRTC session
* `RTCIceCandidate.relatedAddress`
* `RTCIceCandidate.address` and `RTCIceCandidate.port`
RTCIceCandidate: sdpMid property
================================

 The read-only property **`sdpMid`** on the `RTCIceCandidate` interface returns a string
 specifying the media stream identification tag of the media component with which the candidate is associated.
 This ID uniquely identifies a given stream for the component with which the candidate is associated.

 This property can be configured by specifying the value of the `sdpMid` property in the `candidateInfo` options object that is passed to the `RTCIceCandidate()` constructor.
 If you call the constructor with an m-line string instead of the options object, the value of `sdpMid` is extracted from the specified candidate m-line string.

Value
-----

 A string which uniquely identifies the source media component from
 which the candidate draws data, or `null` if no such association exists for the candidate.


**Note:** Attempting to add a candidate (using `addIceCandidate()`) that has a
 value of `null` for both `sdpMid` and `sdpMLineIndex` will throw a `TypeError` exception.


Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-sdpmid |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
RTCIceCandidate: type property
==============================

The **`RTCIceCandidate`** interface's read-only **`type`** specifies the type of candidate the object represents.

 The `type` field's value is set from the `candidateInfo` options object passed to the `RTCIceCandidate()` constructor.
 You can't specify the value of `type` directly in the options object, but its value is automatically extracted from the object's `candidate` a-line (the `cand-type` field), if it's formatted properly.

Value
-----

A string whose value is one of those defined below. These candidate types are listed in order of priority; the higher in the list they are, the more efficient they are.

`host`

The candidate is a host candidate, whose IP address as specified in the `RTCIceCandidate.address` property is in fact the true address of the remote peer.

`srflx`

 The candidate is a server reflexive candidate; the `ip` and port
 are a binding allocated by a NAT for an agent when it sent a
 packet through the NAT to a server. They can be learned by the STUN server and TURN server to represent the candidate's peer anonymously.


`prflx`

 The candidate is a peer reflexive candidate; the `ip` and port
 are a binding allocated by a NAT when it sent a STUN request to represent the candidate's peer anonymously.


`relay`

The candidate is a relay candidate, obtained from a TURN server. The relay candidate's IP address is an address the TURN server uses to forward the media between the two peers.


 If `type` is `null`, that information was missing from the
 `candidate`'s a-line, which will cause
 `RTCPeerConnection.addIceCandidate()` to throw an
 `OperationError` exception.

Examples
--------

 In this example, the candidate's `type` is used to
 present a modified user interface for host candidates (those where the
 `ip` refers directly to the remote peer, rather than
 an intermediary).


```js
if (candidate.type === "host") {
  showHostControls();
} else {
  hideHostControls();
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-type |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* WebRTC API
* Introduction to WebRTC protocols
* WebRTC connectivity
* `RTCIceCandidate.tcpType`
RTCIceCandidate: toJSON() method
================================

The `RTCIceCandidate` method **`toJSON()`** converts the `RTCIceCandidate` on which it's called into JSON.

A stringified version of the object can then be obtained by calling `stringify()` on the returned object.

Syntax
------


```js
toJSON()
```

### Parameters

None.

### Return value

A JSON object with the following properties, which have been set to the corresponding values in the `RTCIceCandidate` object:

`candidate` Optional

 A string describing the network connectivity information for the candidate.
 Additional information can be found in `RTCIceCandidate.candidate`.


`sdpMid` Optional

 A string containing the identification tag of the media stream with which the candidate is associated, or `null` if there is no associated media stream.
 Additional information can be found in `RTCIceCandidate.sdpMid`.


`sdpMLineIndex` Optional

 A number property containing the zero-based index of the m-line with which the candidate is associated, within the SDP of the media description, or `null` if no such associated exists.
 Additional information can be found in `RTCIceCandidate.sdpMLineIndex`.


`usernameFragment` Optional

 A string containing the username fragment (usually referred to in shorthand as "ufrag" or "ice-ufrag").
 This fragment, along with the ICE password ("ice-pwd"), uniquely identifies a single ongoing ICE interaction (including for any communication with the STUN server).
 Additional information can be found in `RTCIceCandidate.usernameFragment`.



**Note:** The returned JSON object has the same form/properties as the `candidateInfo` object that can optionally be passed to the `RTCIceCandidate() constructor` to configure the candidate.

Examples
--------

This simple example obtains a JSON string representing an `RTCIceCandidate` found in the variable `candidate`.


```js
let jsonString = candidate.toJSON().stringify();
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-tojson |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
RTCIceCandidate: protocol property
==================================

 The **`RTCIceCandidate`** interface's read-only **`protocol`** property is a string
 which indicates whether the candidate uses UDP or TCP as its transport protocol.

 The `protocol` field's value is set from the `candidateInfo` options object passed to the `RTCIceCandidate()` constructor.
 You can't specify the value of `protocol` directly in the options object, but its value is automatically extracted from the object's `candidate` a-line, if it's formatted properly.

`protocol` is `null` by default if not specified properly in the SDP, but this is an error condition and will result in a thrown exception when you call `RTCPeerConnection.addIceCandidate()`.

Value
-----

A string that indicates what network protocol the candidate uses:

`tcp`

The candidate, if selected, would use TCP as the transport protocol for its data. The `tcpType` property provides additional information about the kind of TCP candidate represented by the object.

`udp`

The candidate will use the UDP transport protocol for its data. This is the preferred protocol for media interactions because of its better performance profile.



**Note:** If `protocol` is `null` — and `protocol` is supported by the user agent — passing the
 candidate to `addIceCandidate()` will fail, throwing an `OperationError` exception.


Usage notes
-----------

Here's an example candidate a-line from an ICE transaction:
```

a=candidate:4234997325 1 udp 2043278322 192.0.2.172 44323 typ host
```


 The third field, `"udp"`, is the protocol type, indicating that the
 candidate would use the UDP transport protocol.

Examples
--------

 This code snippet examines the value of `protocol` to decide if it should
 look at the value of `tcpType` to see if it's a
 **simultaneous-open** (**S-O**) candidate.


```js
if (candidate.protocol === "tcp") {
  if (candidate.tcpType === "so") {
    adjustForSimultaneousOpen(candidate);
  }
}
```

Specifications
--------------

| Specification |
| --- |
| WebRTC: Real-Time Communication in Browsers # dom-rtcicecandidate-protocol |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.