我尝试通过 html5 音频标签播放一些 mp3 文件。对于桌面来说，这非常有效(使用 Chrome)，但是当涉及到移动浏览器(还有 Chrome(适用于 Android))时，似乎存在一些困难:
我用一些密码保护流，因此流服务器需要找到一个特殊的身份验证cookie(spring security Remember-me)。但不知何故，移动浏览器在通过音频标签访问 mp3 流时不会发送此 cookie。当我直接在地址栏输入流 URL 时，一切正常。
当我搜索丢失的 cookie 时，我发现移动浏览器仍然发送一些 cookie(例如 JSESSIONID)，但不是全部。进一步的调查(使用 PHP 进行快速 PoC)显示，移动浏览器似乎拒绝通过设置了 HttpOnly 标志的音频标签发送 cookie。所以我的问题是:
这是一种指定的行为吗？为什么(Chrome 的)移动版本和桌面版本之间存在差异？是否有办法从客户端控制该行为？
最佳答案
通过更深入地研究 HTTP 包，我发现 Android 浏览器本身并不请求 mp3 流，而是将其委托(delegate)给 stagefright(某些 Android 多媒体客户端)。快速搜索发现，对于旧的 Android 版本(4.0 之前)，stagefright 无法处理 cookie:
- https://code.google.com/p/android/issues/detail?id=17553 <--(状态:垃圾邮件)WTF...
- https://code.google.com/p/android/issues/detail?id=17281
- https://code.google.com/p/android/issues/detail?id=10567
- https://code.google.com/p/android/issues/detail?id=19958
我自己的测试证实了这一点。旧的 stagefright (Android 2.3.x) 根本不发送任何 cookie，来自欧洲 S3 (android 4.1.2、stagefright 1.2) 的 stagefright 仅发送没有 httpOnly 标志的 cookie。
所以我认为每个人都必须自己决定他想要使用哪种解决方案:
- 启用 httpOnly:android 根本无法访问，但很安全
- 禁用 httpOnly:针对 XSS 的安全性较低，但适用于 Android >4.0
- 完全禁用 Cookie 身份验证:不安全，但适用于所有人
注意:简单地禁用 httpOnly 的问题是，您的整个应用程序容易受到 cookie 劫持者的攻击。另一种可能的解决方案是为流提供一个特殊的 Rememberme Cookie(不带 httpOnly)，并使用另一个启用了 httpOnly 的 Rememberme Cookie。
关于html5-audio - 移动浏览器是否通过 HTML5 音频标签发送 httpOnly cookie？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16310552/