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

问题描述

我正尝试通过将Web Audio API与createMediaElementSourceSource（）一起使用来创建播客网络的音频可视化模型，该模型与模型在本教程中进行了解释。到目前为止，我已经使它在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策略有关，因为我也尝试使用此音频源，它在所有浏览器中都很好用。我的怀疑是由于此标准引起的Web音频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.

它仅在野生动物园中发生的事实让我祈祷，在我或服务器主机的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();

推荐答案

简短答案：服务的维护者发送<对您的请求的code> 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 重定向响应进行回复具有位置：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屋！