Firefox与Chrome是否支持HTTP WebPush推送消息回执功能？

RFC8030第5.1节明确规定：

"The push service MUST support delivery confirmations"（推送服务必须支持投递确认）

但在实际落地中，这一要求的执行情况并不统一，具体可以从主流推送服务和开发实践两个角度来看：

• 主流浏览器关联的推送服务：

  • Chrome依赖的Firebase Cloud Messaging（FCM）：仅在特定场景下提供投递确认——比如消息成功送达在线设备时，会返回对应的回执；但如果设备离线，消息进入队列后，后续的实际送达回执并不提供，开发者只能知道消息被FCM接收，无法确认最终是否到用户设备。
  • Firefox的推送服务：对投递确认的支持相对更贴近协议要求，当消息成功推送到在线设备时会返回明确的确认信号，离线消息送达后也会尝试回调开发者的端点，但可靠性不如在线场景。
  • Safari的APNs：本身对Web Push的支持较晚，投递确认仅针对消息是否被APNs接收，无法追踪到用户设备的实际送达状态。

• 第三方推送服务：
  大部分第三方Web Push服务商（如OneSignal、PushEngage等）会基于底层的FCM/APNs做封装，它们提供的"投递确认"大多是指消息被底层推送服务接收，而非真正触达用户设备；只有少数服务商通过额外的客户端上报机制来模拟更精准的送达确认，但这已经超出了RFC8030协议定义的服务端确认范畴。

• 开发中的实际痛点：
  很多开发者在实践中发现，完全符合RFC8030要求的推送服务几乎不存在，协议里的"MUST"并没有被所有实现严格遵守。这导致开发者无法准确统计消息的实际触达率，只能依赖推送服务商提供的"已发送"数据，而非"已送达"数据。

内容的提问来源于stack exchange，提问作者0xZ3RR0