Web MIDI API

Web Midi API 是一个由 强大功能， 其 名称为 "midi"。它 通过定义以下与权限相关的标志，与 Permissions 集成：

权限描述符 类型

WebIDLdictionary MidiPermissionDescriptor : PermissionDescriptor {
  boolean sysex = false;
};

{name: "midi", sysex: true} 强于 {name: "midi", sysex: false}。

Web Midi API 定义了一个名为 "midi" 的 策略控制功能， 其 默认 允许列表为 'self'。

WebIDLpartial interface Navigator {
  [SecureContext]
  Promise <MIDIAccess> requestMIDIAccess(optional MIDIOptions options = {});
};

requestMIDIAccess() 方法

调用时，返回一个 Promise 对象，表示对用户系统上 MIDI 设备访问权限的请求。

请求 MIDI 访问权限SHOULD 提示用户授予对 MIDI 设备的访问权限，特别是在请求 System Exclusive 访问权限时。 在某些场景中，此权限可能已经被隐式或显式授予， 在这种情况下该提示可能不会出现。如果用户给予明确许可， 或调用以其他方式获得批准，则所给出的 Promise 会被解决。 底层系统可以选择允许用户选择要暴露给此 API 的特定 MIDI 接口（即逐个接口挑选）， 尽管这不是必需的。系统还可以根据是否请求 System Exclusive 支持来选择是否提示用户，因为 System Exclusive 访问具有更大的隐私和 安全影响。

如果用户拒绝，或调用因任何其他原因被拒绝， Promise 将以 DOMException 参数被拒绝。

即使并非所有给出的 Promise 都已敲定，也允许多次调用 requestMIDIAccess()。

当调用 requestMIDIAccess() 方法时，用户代理 MUST 运行以下步骤：

1. 令 promise 为一个新的 Promise 对象，并令 resolver 为其关联的 resolver。

2. 返回 promise，并异步运行以下步骤。

3. 令 document 为调用上下文的 Document。

4. 如果 document 未被 允许 使用名为 midi 的 策略控制 功能，则跳转到下面标记为 failure 的步骤。

5. 可选地，例如基于先前建立的用户偏好、 出于安全原因，或由于平台限制，跳转到下面标记为 failure 的步骤。

6. 可选地，例如基于先前建立的用户偏好，跳转到下面标记为 success 的步骤。

7. 以用户代理特定的方式提示用户授予权限，以便向入口脚本的源提供一个 MIDIAccess 对象，该对象表示对用户 MIDI 设备的控制。此 提示可以取决于是否请求了 System Exclusive 支持，并且可以允许用户启用或禁用该访问权限。

   如果权限被拒绝，则跳转到下面标记为 failure 的步骤。如果用户从不响应， 此算法将永远不会越过此步骤继续进行。如果权限 被授予，则继续以下步骤。

8. success：令 access 为一个新的 MIDIAccess 对象。（可以多次调用 requestMIDIAccess()；这可能会多次提示用户， 因此可能不是最佳实践，并且每次不会返回同一个 MIDIAccess 实例。）

9. 调用 resolver 的 accept(value) 方法， 并以 access 作为 value 实参。

10. 终止这些步骤。

11. failure：令 error 为一个新的 DOMException。 如果用户或其安全设置拒绝应用程序使用所请求的选项 创建 MIDIAccess 实例，或者如果该错误是 document 未被 允许 使用该功能的结果，则此异常的 .name 应为 "NotAllowedError"； 如果页面将因用户导航而被关闭，则为 "AbortError"； 如果底层系统引发任何错误，则为 "InvalidStateError"； 否则应为 "NotSupportedError"。

12. 调用 resolver 的 reject(value) 方法， 并以 error 作为 value 实参。

WebIDLdictionary MIDIOptions {
  boolean sysex;
  boolean software;
};

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIInputMap {
  readonly maplike <DOMString, MIDIInput>;
};

MIDIInputMap 是一个 maplike 接口，其值为 MIDIInput 实例，键为其 ID。

此类型用于表示所有当前可用的 MIDI 输入 端口。

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIOutputMap {
  readonly maplike <DOMString, MIDIOutput>;
};

MIDIOutputMap 是一个 maplike 接口，其值为 MIDIOutput 实例，键为其 ID。

此类型用于表示所有当前可用的 MIDI 输出 端口。

此接口提供用于列出 MIDI 输入和输出设备，并获取对单个设备的访问权限的方法。

WebIDL[SecureContext, Exposed=(Window,Worker), Transferable] interface MIDIAccess: EventTarget {
  readonly attribute MIDIInputMap inputs;
  readonly attribute MIDIOutputMap outputs;
  attribute EventHandler onstatechange;
  readonly attribute boolean sysexEnabled;
};

inputs

系统可用的 MIDI 输入端口。

outputs

系统可用的 MIDI 输出端口。

onstatechange

当新端口连接，或现有端口更改 state 属性时调用的处理程序。

此 事件 处理程序，类型为 MIDIConnectionEvent，MUST 由所有实现 MIDIAccess 接口的对象支持。

注

必须理解，将 EventHandler 留在此对象上会阻止该对象被垃圾回收；当使用完 MIDIAccess 后，应移除任何 onstatechange 监听器。

每当先前不可用的 MIDI 端口变为可用，或现有端口更改 state 属性时，用户代理 SHOULD 运行以下步骤：

1. 令 port 为与新近可用的端口或现有端口 相对应的 MIDIPort。
2. 在 MIDIAccess 上 触发一个 名为 "statechange" 的事件， 使用 MIDIConnectionEvent，并将 port 设置为 port。

sysexEnabled

此属性告知用户，在此 MIDIAccess 上是否启用了 System Exclusive 支持。

此接口表示 MIDI 输入或输出端口。

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIPort: EventTarget {
  readonly attribute DOMString id;
  readonly attribute DOMString? manufacturer;
  readonly attribute DOMString? name;
  readonly attribute MIDIPortType type;
  readonly attribute DOMString? version;
  readonly attribute MIDIPortDeviceState state;
  readonly attribute MIDIPortConnectionState connection;
  attribute EventHandler onstatechange;
  Promise <MIDIPort> open();
  Promise <MIDIPort> close();
};

id

端口的唯一 ID。开发者可用它记住用户为其应用程序选择的端口。 用户代理 MUST 确保 id 仅对该端口唯一。 用户代理 SHOULD 确保该 id 在应用程序的多个实例之间保持不变 - 例如，当系统重新启动时 - 以及当设备从系统中移除时保持不变。 应用程序可能希望在本地缓存这些 id，以重新创建 MIDI 设置。 某些系统可能不支持完全唯一的持久标识符；在这种情况下，当另一个接口 被添加到系统或从系统移除时，维护标识符会更具挑战性。 （这可能会打乱所请求端口的索引。）预期系统会尽其所能， 在 MIDI API 的多个实例之间匹配端口：例如，实现可以不透明地 使用端口接口制造商、名称和索引的某种哈希作为 id， 这样对该端口 id 的引用在插入时很可能匹配该端口。 应用程序可以使用 MIDIPort 的 id 比较来测试相等性。

manufacturer

端口的制造商。

name

端口的系统名称。

type

用于区分端口是输入端口还是输出端口的描述符属性。对于 MIDIOutput，此属性 MUST 为 "output"。对于 MIDIInput，此属性 MUST 为 "input"。

version

端口的版本。

state

设备的状态。

connection

到设备的连接状态。

onstatechange

当现有端口更改其 state 或 connection 属性时调用的处理程序。

此 事件 处理程序，类型为 "statechange"，MUST 由所有实现 MIDIPort 接口的对象支持。

注

必须理解，将 EventHandler 留在此对象上会阻止该对象被垃圾回收；当使用完 MIDIPort 后，应移除任何 onstatechange 监听器。

open

使与 MIDIPort 相对应的 MIDI 设备显式可用。请注意，为了使用 MIDIPort，并不要求调用此方法 - 在 MIDIOutput 上调用 send()， 在 MIDIInput 上附加 MIDIMessageEvent EventHandler， 或在 MIDIInput 上添加 MIDIMessageEvent EventListener 都会导致隐式 open()。底层实现可能无需响应此调用执行任何操作。 然而，某些底层实现可能无法支持对 MIDI 设备的共享访问， 因此使用显式 open() 和 close() 调用将使 MIDI 应用程序能够 可预测地控制对设备的这种独占访问。

调用时，此方法返回一个 Promise 对象，表示对用户系统上给定 MIDI 端口 访问权限的请求。

如果端口设备的状态为 "connected"，当已获得对该端口的访问权限 （并且该端口已准备好进行输入或输出）时，所给出的 Promise 会被解决。

如果无法访问已连接的端口（例如，该端口已在仅允许独占访问的平台中被使用）， 则 Promise 会被拒绝（如果有）。

如果在 "disconnected" 的端口上调用 open()，该端口的 .connection 将转换为 "pending"， 直到该端口变为 "connected"，或对它的所有引用都被丢弃。

即使并非所有给出的 Promise 都已敲定，也允许多次调用 open()。

当调用此方法时，用户代理 MUST 运行 打开 MIDIPort 的算法：

1. 令 promise 为一个新的 Promise 对象，并令 resolver 为其关联的 resolver。

2. 返回 promise，并异步运行以下步骤。

3. 令 port 为给定的 MIDIPort 对象。

4. 如果设备的 connection 已经是 "open"（例如，已在此 MIDIPort 上调用 open()， 或端口已被隐式打开），则跳转到下面标记为 success 的步骤。

5. 如果设备的 connection 为 "pending"（即连接已被打开， 而设备随后断开连接），则跳转到下面标记为 success 的步骤。

6. 如果设备的 state 为 "disconnected"，则将 connection 属性更改为 "pending"，并将一个新的 MIDIConnectionEvent 加入 MIDIAccess 的 statechange 处理程序队列，以及 MIDIPort 的 statechange 处理程序队列， 然后跳转到下面标记为 success 的步骤。

7. 尝试在系统中获取对给定 MIDI 设备的访问权限。如果设备不可用（例如已被另一个进程使用且无法打开， 或已断开连接），则跳转到下面标记为 failure 的步骤。 如果设备可用且已获得访问权限，则继续以下步骤。

8. 将 MIDIPort 的 connection 属性更改为 "open"， 并将一个新的 MIDIConnectionEvent 加入 MIDIAccess 的 statechange 处理程序队列，以及 MIDIPort 的 statechange 处理程序队列。

9. 如果此端口是输出端口，并且存在任何带有未来时间戳的已排队发送数据， 则异步开始发送这些数据。

10. success：调用 resolver 的 accept(value) 方法，并以 port 作为 value 实参。

11. 终止这些步骤。

12. failure：令 error 为一个新的 DOMException。 如果端口不可用，则此异常的 .name 应为 "InvalidAccessError"。

13. 调用 resolver 的 reject(value) 方法， 并以 error 作为 value 实参。

close

使与 MIDIPort 相对应的 MIDI 设备显式不可用（随后将状态从 "open" 更改为 "closed"）。请注意，成功调用此方法将导致 MIDI 消息不再被传递给 MIDIInput 上的 MIDIMessageEvent 处理程序 （尽管设置新的处理程序会导致隐式 open()）。

底层实现可能无需响应此调用执行任何操作。然而，某些底层实现 可能无法支持对 MIDI 设备的共享访问，而显式 close() 调用使 MIDI 应用程序能够确保 其他应用程序可以获得对设备的访问权限。

调用时，此方法返回一个 Promise 对象，表示对用户系统上给定 MIDI 端口 访问权限的请求。当端口已关闭（因此，在独占访问系统中，该端口可供 其他应用程序使用）时，所给出的 Promise 会被解决。如果端口断开连接， 则 Promise 会被拒绝。

即使并非所有给出的 Promise 都已敲定，也允许多次调用 close()。

当调用 close() 方法时，用户代理 MUST 运行以下步骤：

1. 令 promise 为一个新的 Promise 对象，并令 resolver 为其关联的 resolver。

2. 返回 promise，并异步运行以下步骤。

3. 令 port 为给定的 MIDIPort 对象。

4. 如果端口已关闭（其 .connection 为 "closed" - 例如，端口尚未被 隐式或显式打开，或已在此 MIDIPort 上调用 close()）， 则跳转到下面标记为 closed 的步骤。

5. 如果端口是输入端口，则跳到下一步。如果输出端口的 .state 不是 "connected"， 或其 .connection 为 "pending"，则清除所有已排队发送数据，并跳到下一步。 清除系统中任何带有未来时间戳的已排队发送数据，然后在继续下一步之前， 完成发送任何没有时间戳或时间戳位于过去或现在的发送消息。

6. 如果底层系统中对端口的访问已打开，则关闭该访问，并释放底层系统中的 任何阻塞资源。

7. 将 MIDIPort 的 connection 属性更改为 "closed"， 并将一个新的 MIDIConnectionEvent 加入 MIDIAccess 的 statechange 处理程序队列，以及 MIDIPort 的 statechange 处理程序队列。

8. closed：调用 resolver 的 accept(value) 方法，并以 port 作为 value 实参。

每当与 MIDIPort 相对应的 MIDI 端口更改 state 属性时，用户代理 SHOULD 运行以下步骤：

1. 令 port 为该 MIDIPort。

2. 在 MIDIPort 上 触发一个事件， 其名称为 statechange，并在 MIDIAccess 上触发 statechange， 使用 MIDIConnectionEvent，并将 port 属性设置为 port。

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIInput: MIDIPort {
  attribute EventHandler onmidimessage;
};

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIOutput : MIDIPort {
  undefined send(sequence<octet> data, optional DOMHighResTimeStamp timestamp = 0);
  undefined clear();
};

WebIDLenum MIDIPortType {
  "input",
  "output",
};

WebIDLenum MIDIPortDeviceState {
  "disconnected",
  "connected",
};

WebIDLenum MIDIPortConnectionState {
  "open",
  "closed",
  "pending",
};

当收到 MIDI 消息时，实现此接口的事件对象会被传递给 MIDIInput 的 onmidimessage 处理程序。 请注意，DOM Event 的 timeStamp 属性被定义为 DOMHighResTimeStamp， 并表示事件被接收或将被发送时的高精度时间。

WebIDL[SecureContext, Exposed=(Window,Worker)]
interface MIDIMessageEvent : Event {
  constructor(DOMString type, optional MIDIMessageEventInit eventInitDict = {});
  readonly attribute Uint8Array? data;
};

data

一个包含单个 MIDI 消息的 MIDI 数据字节的 Uint8Array。

WebIDLdictionary MIDIMessageEventInit: EventInit {
  Uint8Array data;
};

当新端口变为可用（例如，当 MIDI 设备首次插入计算机时）， 当先前可用的端口变为不可用，或再次变为可用（例如，当 MIDI 接口 断开连接后又重新连接时），实现此接口的事件对象会被传递给 MIDIAccess 的 onstatechange 处理程序， 并且（如果存在）也会被传递给任何引用该端口的 MIDIPort 的 onstatechange 处理程序。

当 MIDIPort 处于 "pending" 状态且设备重新连接到宿主系统时， 在触发 statechange 事件之前，会在其上运行 打开 MIDIPort 的算法，以尝试重新打开端口。如果此转换失败 （例如，端口被底层系统中的其他事物保留，因此不可用），connection 状态会变为 "closed"，否则会转换回 "open"。这是在设备 state 变化的 statechange 事件之前完成的，以便该事件既反映最终的 connection 状态，也反映设备 state。

某些底层系统可能不提供设备连接状态的通知事件；这类系统可能因不频繁轮询 新设备而出现较长延迟。因此，建议不要过度依赖连接事件。

WebIDL[SecureContext, Exposed=(Window,Worker)]
interface MIDIConnectionEvent : Event {
  constructor(DOMString type, optional MIDIConnectionEventInit eventInitDict = {});
  readonly attribute MIDIPort? port;
};

port

已连接或断开连接的端口。

WebIDLdictionary MIDIConnectionEventInit: EventInit {
  MIDIPort port;
};

一种令人担忧的理论攻击涉及对 USB-MIDI 设备进行恶意 固件更新。一般来说，USB 设备可以根据其设备描述符 执行操作，而该描述符由 USB 设备本身发送。如果 USB-MIDI 设备的 固件可以修改所发送的描述符，它 就可以让自己表现为人机接口设备。这 可能允许恶意网站读取或注入宿主计算机上的 按键或其他事件，从而可能导致系统被完全攻陷。

攻击将按如下方式进行：

1. 恶意站点诱骗用户授予 Web MIDI 权限。
2. 恶意站点枚举连接到用户机器的 MIDI 设备， 并识别出易受攻击的设备。
3. 恶意站点向易受攻击的设备发送一组预先制作的 MIDI 消息， 通过覆盖其固件并向其 USB 描述符添加人机 接口设备来攻陷该设备。
4. 被攻陷的设备注入按键，以下载或以其他方式复制 预先制作的安全漏洞利用程序并执行它，从而攻陷系统。

为了促成上述攻击，一个 MIDI 设备 需要满足以下所有条件：

• 容易受到恶意固件更新攻击。以下所有条件都必须为真：
  • 具有用户可编程固件。许多 MIDI 设备具有可重新编程固件。没有这种固件的设备 不易受此攻击。
  • 允许通过发送 MIDI 消息来更新固件。许多 MIDI 设备使用 System Exclusive 消息执行固件 更新。 这是 System Exclusive 消息的一种常见用途。从技术上讲，可以制造一种 使用非 System Exclusive 消息 来执行固件更新的设备，但这并不是 非 System Exclusive 消息的 预期用途。其他设备可能使用带外 USB 通信， 或要求用户将存储设备直接连接到 MIDI 设备来执行固件 更新，这无法使用 Web MIDI API 完成，因此不易受此攻击。
  • 允许在设备上没有显式用户交互的情况下进行固件更新。 已知存在一些 MIDI 设备不需要任何用户交互 即可启动固件更新。大多数 MIDI 设备要求用户先将它们置于 特殊更新模式，例如按住某个按钮或选择菜单选项， 除非攻击者诱骗用户配合，否则不易受攻击。
• 是 USB-MIDI 设备。大多数现代 MIDI 设备 都有 USB MIDI 接口。一些较旧的 MIDI 设备只有串行连接，因此不会 促成此攻击。
• 该 MIDI 设备的固件必须能够 修改 USB 控制器的固件。许多 MIDI 设备 的 USB 控制器固件不能从主固件寻址，因此不会 促成此攻击。

容易受到恶意固件更新影响但不满足其他条件的 MIDI 设备，不能被此攻击用于攻陷 宿主系统。恶意固件更新仍然可能导致这些 MIDI 设备停止 工作或以不期望的方式运行。

为缓解此风险，实现者应在其实现中强调以下事项：

• 以告知用户固件更新风险的方式实现 requestMIDIAccess()， 例如通过权限提示中的文本说明。
• 按规定实现 SecureContext，以防止用户发起的合法 固件更新被修改。
• 按规定处理 sysex 参数，以鼓励开发者仅在必要时才请求 System Exclusive 消息， 因为大多数固件更新使用 System Exclusive 消息。

显式允许或阻止已知 MIDI 设备列表也可能有助于缓解此特定攻击， 但许多小公司和个人会构建 MIDI 设备，并且许多 MIDI 设备 已不再受支持，因此这样做会显著降低 Web MIDI API 的可用性。

除了识别可用端口所带来的指纹识别问题之外，还存在 发送和接收 MIDI 消息方面的问题。这些问题将在 下文更深入地探讨。

MIDI 消息可分为 System Exclusive 消息和短消息（非 System Exclusive 消息）。 System Exclusive 消息还可进一步细分为 Universal System Exclusive 消息，例如常见的 MIDI Time Code 和 MIDI Sample Dump Standard，以及设备特定的消息，例如“Roland Jupiter-80 合成器的音色控制数据”，这类消息不适用于其他设备。

在讨论安全问题之前，先考察 MIDI 使用这些 功能所支持的场景会很有帮助：

• 从 MIDI 设备接收短消息 - 这使得可以从键盘、鼓垫、吉他、管乐控制器、 DJ/controllerist 控制器等获取输入，并使用这些消息作为 输入来控制 Web Audio API 中的乐器和功能， 以及其他控制场景。MIDI 是价值数十亿美元的音乐制作 行业用于将旋钮和按钮等物理控制器连接到计算机的首选协议， 无论是在专业/准专业音频和媒体应用中，还是在 Garageband 等 消费级应用中。
• 向 MIDI 设备发送短消息 - 人们很容易说发送要明显不那么有趣，因为在当今市场中， 像硬件合成器这样的已连接输出设备场景较少见。主要例外是， 许多 MIDI 控制器的指示灯可以由外部宿主控制，这使它们 显著更有用。例如，非常流行的 Novation Launchpad 控制器 使用发送给它的 MIDI note on/off 消息来打开/关闭按钮并 改变按钮颜色。几乎所有 DJ 控制器也是如此。
• 发送和接收 System Exclusive 消息 - 对于与高端硬件设备进行更高级的通信， 需要 System Exclusive 消息。 一些常见的 MIDI 命令也作为 Universal System Exclusive 消息发送，例如 MIDI Machine Control - 通用的开始/停止/倒带/快进 命令。许多设备使用设备特定的 System Exclusive 消息来编程音色、发送高级控制器 消息、下载固件等，这些都是 Web MIDI 中需求很高的场景。 一些设备将 System Exclusive 用作直接控制协议， 因为它们可以在单个“消息”中打包更多数据，并且 大多数设备使用 System Exclusive 作为在 较廉价的计算机存储上保存和恢复音色及配置信息的方式。 几家主要音乐硬件生产商已表达了强烈兴趣，希望使用 Web MIDI 为其硬件提供基于 Web 的配置和编程接口。简而言之， 完全禁用 System Exclusive 并不只是 禁用高端场景。

这些场景各自的潜在安全影响如下：

• 向 MIDI 设备发送短消息 - 发送 note-on/note-off/controller 消息可能导致已连接设备播放声音， 包括（在 Mac 和 Windows 上）任何默认虚拟合成器。这本身 不会造成任何令人担忧的暴露 - 你已经可以通过 <audio> 或 Web Audio 在没有交互的情况下发出声音。 一些已连接设备可能是专业灯光控制系统，因此有可能控制 舞台灯光；然而，这很少见，并且没有已知系统能够仅基于 短消息造成持久损害或信息泄漏。最坏情况下，恶意页面可以 闪烁灯光，而用户可以关闭页面并重置其灯光控制器。关于 发送短消息的额外问题类似于任何音频输出 - 你无法覆盖 用户信息或暴露用户信息，但你可以让声音发生、改变音色， 或（在少见配置中）切换灯光 - 但这种影响是非破坏性的， 且不是持久性的。
• 从 MIDI 设备接收短消息 - 接收 note-on/note-off/controller 消息不会造成信息暴露 或安全问题，因为接收到的不是标识性数据，而只是控制器消息流 - 所有这些消息都必须由用户在该 MIDI 设备上发起（时钟类消息除外）。 这类似于监听键盘、鼠标、移动/笔记本加速度计、触摸输入 或游戏手柄事件；不会暴露额外信息，并且除时钟信号之外的 所有消息都必须由用户发起。
• 发送和接收 System Exclusive 消息 - 这是最大的担忧，因为可以编写代码来寻找对 System Exclusive 消息的系统特定响应， 这可能识别可用硬件，然后使用它下载数据 - 例如存储在采样器中的采样 - 或替换该数据 （擦除设备中的采样数据或音色），尽管这两种场景都必须 针对特定设备编写代码。也有可能某些采样器允许通过 System Exclusive 消息开始录制采样 - 因此，如果该采样器 恰好连接了专用麦克风（实际中不常见，但可能），就可能编写 针对特定设备的代码来录制一小段声音采样，然后在没有进一步 用户干预的情况下将其上传到网络。你无法从设备流式传输音频， 而且大多数采样器内存相当有限，MIDI Sample Dump sysex 是一种 缓慢的数据传输方式 - 它必须转码为 7 位 - 因此不太可能 长时间监听。更明确的指纹识别是一个问题，因为音色信息/ 存储的采样/用户配置可能唯一标识系统。同样，这需要大量 设备特定代码；不存在标准化的“获取所有音色并哈希”的能力。 这表明 System Exclusive 消息属于其自身的安全类别。 由于这种较少受限的潜在影响，在 API 中单独区分 SysEx 请求 似乎是一个好主意，以便更谨慎地提供用户安全 钩子。建议的 安全模型明确允许用户代理在授予 MIDI 设备访问权限之前要求用户批准，尽管目前并不要求提示用户 进行此批准 - 但也详细说明了必须将 System Exclusive 支持作为 该请求的一部分来请求。