前端 JavaScript 请求被 302 重定向但最终失败 [英] Frontend JavaScript request gets 302-redirected but ultimately fails

问题描述

我正在尝试为播客网络创建音频可视化，使用带有 createMediaElementSource() 的 Web 音频 API，非常类似于模型 在本教程中解释.到目前为止，我已经让它在 Chrome 中正常工作，并且 你可以在这里看到它(注意:点击红色框开始它).

I'm trying to create an audio visualization for a podcast network, using the Web Audio API with createMediaElementSource() very similarly to the model explained in this tutorial. So far I've gotten it to work fine in Chrome, and you can see it here (note: click on the red box to start it).

更新:根据评论中的讨论，现在很清楚问题的发生是因为请求通过 302 重定向重定向到另一个 URL.

Update: Based on discussion in the comments, it’s now become clear that the problem happens because the request gets redirected to another URL, by way of a 302 redirect.

然而，Safari 拒绝工作，虽然它显示了正在播放的曲目，但它没有输出声音，也没有产生可视化效果.我相信这与我请求音频的服务器的 CORS 策略有关，因为我也尝试过使用 这个音频源，它适用于所有浏览器.我怀疑这是由于 这个标准 的问题网络音频 API.

However, Safari refuses to work, outputting no sound and producing no visualization although it shows the track playing. I believe it has to do with the CORS policy of the server I'm requesting the audio from, because I've alternatively tried using this audio source and it works great in all browsers. My suspicion is it's an issue arising due to this standard of the web audio API.

它只发生在 safari 中的事实让我祈祷在他们的 CORS 策略中我端或服务器主机端有一些简单的语法解决方案来让它发挥作用.我希望有人能准确指出导致此问题的标头请求/响应中出了什么问题.如果我需要提供更多信息，请告诉我.我在下面留下了我的 AudioContext 代码的简化版本，以防出现问题.

The fact that it only happens in safari makes me pray that there's some easy syntactic solution either on my end or the server host's end in their CORS policy to get this to work. I'm hoping someone can point out exactly what's going wrong in the header requests/responses that's causing this problem. Let me know if there's any more information I need to provide. I've left a simplified version of my AudioContext code below in case a problem surfaces there.

//definitions
var url='https://rss.art19.com/episodes/72a3bc7e-118a-4171-8be4-125913860ef7.mp3';
//in safari it works with the link below, but not with any art19 link such as the one above.
//https://s3-us-west-2.amazonaws.com/s.cdpn.io/858/outfoxing.mp3
var audiotag=document.querySelector('audio');
var AudioContext = window.AudioContext || window.webkitAudioContext;
var context;
var statcontext;
var analyser;
var source;
var loopf;

//on load:
context=new AudioContext();
audiotag.crossOrigin="anonymous";
audiotag.preload="none";
audiotag.src=url;
source=context.createMediaElementSource(audiotag);
analyser=context.createAnalyser();
source.connect(analyser);
analyser.connect(context.destination);
analyser.smoothingTimeConstant=0.85
analyser.fftSize = 16384;

//later, on user input(clicking on red bar):
var bufferLength = analyser.frequencyBinCount;
var dataArray = new Uint8Array(bufferLength);
function updateDisplay() {
  loopf=requestAnimationFrame(updateDisplay);
  analyser.getByteFrequencyData(dataArray);
  draw(dataArray.slice(100,150),-100,100);
}
context.resume();
audiotag.play();
updateDisplay();

推荐答案

简短回答:向您的请求发送 302 响应的服务维护人员应更新其后端配置，以便添加 Access-Control-Allow-Origin 标头到 302 响应(以及任何其他 3xx 重定向响应)——不仅仅是 200 好的回复.

Short answer: The maintainers of the service sending the 302 response to your request should update their backend config such that it adds the Access-Control-Allow-Origin header to 302 responses (and any other 3xx redirect responses) — not just to 200 OK responses.

如果你不能让他们这样做，那么基本上你只有另外两个选择:

If you can’t get them to do that, then basically you only have exactly two other options:

1. 更改您的前端代码以通过 CORS 代理发出请求；否则
2. 根本不要从您的前端代码发出请求，而是完全从您的后端服务器端代码(其中 同源政策 不适用).

1. Change your frontend code to make the request through a CORS proxy; or else
2. Don’t make the request from your frontend code at all, but instead do it completely from your backend server-side code (where the same-origin policy doesn’t apply).

说明

发生了什么:

1. 您的前端代码向 https://rss.art19.com/episodes/….mp3 URL 发出请求.

https://rss.art19.com 服务器使用 302 重定向响应进行回复，该响应具有 Location: https://content.production.cdn.art19.com/…episodes/….mp3 标题.

The https://rss.art19.com server replies to with a 302 redirect response that has a Location: https://content.production.cdn.art19.com/…episodes/….mp3 header.

浏览器接收到 302 响应并检查响应标头以查看是否有 Access-Control-Allow-Origin 标头.如果没有，浏览器会阻止您的代码访问来自 https://content.production.cdn.art19.com/....mp3 重定向 URL 的响应.相反，浏览器会停止并抛出异常.

The browser receives that 302 response and checks the response headers to see if there’s an Access-Control-Allow-Origin header. If there isn’t, the browser blocks your code from accessing the response from the https://content.production.cdn.art19.com/….mp3 redirect URL. Instead the browser will stop and throw an exception.

您有时可以通过获取重定向 URL 并将其用作前端代码中的请求 URL 来解决此问题.例如，不要在代码中使用 https://rss.art19.com/episodes/….mp3，而是使用 https://content.production.cdn.art19.com/…episodes/….mp3 — 因为来自该 URL 的 200 OK 响应确实包含 Access-Control-Allow-Origin 标头).

You can sometimes fix this problem by taking the redirect URL and using it as the request URL in your frontend code. For example, rather than using https://rss.art19.com/episodes/….mp3 in your code, use https://content.production.cdn.art19.com/…episodes/….mp3 — since the 200 OK response from that URL does include the Access-Control-Allow-Origin header).

但在实践中的许多或大多数情况下，该策略行不通——因为抢先识别重定向 URL 将是什么是不可行的.

But in many or most cases in practice, that strategy won’t work — because it’s not feasible to preemptively identify what the redirect URL will be.

请注意，浏览器有意不将重定向 URL 暴露给前端代码.因此，从前端代码中以编程方式获取重定向 URL 并使用它执行另一个请求是不可能的.

Note that, by design, browsers intentionally don’t expose redirect URLs to frontend code. So it’s impossible from frontend code to programatically get a redirect URL and do another request with it.

这篇关于前端 JavaScript 请求被 302 重定向但最终失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！