Nginx MP3下载206部分内容HTTP响应

Nginx MP3下载206部分内容HTTP响应,http,nginx,download,mp3,Http,Nginx,Download,Mp3,全部: 我能够通过Nginx(1.19.2)成功浏览MP3网站并播放MP3流 但是,当尝试通过Nginx下载MP3时,我收到一个206部分内容HTTP响应: 192.168.0.154 - - [07/Nov/2020:10:25:22 +0000] "GET music.mp3 HTTP/1.1" 206 1982193 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x6

全部:

我能够通过Nginx(1.19.2)成功浏览MP3网站并播放MP3流

但是,当尝试通过Nginx下载MP3时,我收到一个206部分内容HTTP响应:

192.168.0.154 - - [07/Nov/2020:10:25:22 +0000] "GET music.mp3 HTTP/1.1" 206 1982193 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38"
{"url":"https:\/\/example.com\/download\/2770587","isSuccess":1}
客户端数据包跟踪显示了来自Nginx的RST的206部分内容HTTP响应:

3390    42.119998   192.168.0.154   192.168.0.2 TCP 54  61978 → 80 [ACK] Seq=526 Ack=2293125 Win=1629440 Len=0
3391    42.120434   192.168.0.2 192.168.0.154   HTTP    347 HTTP/1.1 206 Partial Content  (audio/mpeg)
3392    42.120449   192.168.0.154   192.168.0.2 TCP 54  61978 → 80 [ACK] Seq=526 Ack=2293418 Win=1629184 Len=0
4375    69.116574   192.168.0.154   192.168.0.2 TCP 54  [TCP Window Update] 61978 → 80 [ACK] Seq=526 Ack=2293418 Win=4219392 Len=0
4984    87.122995   192.168.0.154   192.168.0.2 TCP 55  [TCP Keep-Alive] 61978 → 80 [ACK] Seq=525 Ack=2293418 Win=4219392 Len=1
4985    87.123324   192.168.0.2 192.168.0.154   TCP 66  [TCP Keep-Alive ACK] 80 → 61978 [ACK] Seq=2293418 Ack=526 Win=6912 Len=0 SLE=525 SRE=526
5761    117.117822  192.168.0.2 192.168.0.154   TCP 60  80 → 61978 [FIN, ACK] Seq=2293418 Ack=526 Win=6912 Len=0
5762    117.117911  192.168.0.154   192.168.0.2 TCP 54  61978 → 80 [ACK] Seq=526 Ack=2293419 Win=4219392 Len=0
7291    162.122574  192.168.0.154   192.168.0.2 TCP 55  [TCP Keep-Alive] 61978 → 80 [ACK] Seq=525 Ack=2293419 Win=4219392 Len=1
7292    162.123048  192.168.0.2 192.168.0.154   TCP 60  [TCP Keep-Alive ACK] 80 → 61978 [ACK] Seq=2293419 Ack=526 Win=6912 Len=0
7591    173.888730  192.168.0.154   192.168.0.2 TCP 54  61978 → 80 [FIN, ACK] Seq=526 Ack=2293419 Win=4219392 Len=0
7594    173.889906  192.168.0.2 192.168.0.154   TCP 60  80 → 61978 [RST] Seq=2293419 Win=0 Len=0
我试过几种不同的浏览器(如Chrome、Edge等)都有同样的问题

直接浏览而不使用Nginx时,下载成功

你知道为什么使用Nginx下载MP3会失败吗

非常感谢

加里

编辑:

我发现失败的请求正在对Nginx的端口443进行后续异步AJAX调用,在该端口,连接失败,针对我的自签名证书出现了“证书未知”

单击链接方法:

GET http://example.com/ajax/inc/1488440 HTTP/1.1
Host: example.com
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://example.com/mp3/search?keywords=california+gurls
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=k6o4mq4np28bdr6n2g2pbgq190; zvAuth=1; zvLang=0; ZvcurrentVolume=100; nua=Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20Win64%3B%20x64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F86.0.4240.75%20Safari%2F537.36; asus_token=81G3BJcZjrt06SpsxUrh; z1_n=5

HTTP/1.1 200 OK
Server: nginx/1.19.2
Date: Sun, 08 Nov 2020 07:38:33 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d3d5b5d9e0cbf7321ca040f0b126eb6631604821113; expires=Tue, 08-Dec-20 07:38:33 GMT; path=/; domain=.example.com; HttpOnly; SameSite=Lax; Secure
Vary: Accept-Encoding
CF-Cache-Status: DYNAMIC
cf-request-id: 064863f2fb00000b786e0c5000000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=uoLAfVO2XqMqj6FJI%2BwyHFz52QFckDptxRfYjClxWfJvGUxnyAlsIR5Im37T5tC2j%2Big2WIgIfXajj0EWpPBMCxdTtC5ZA%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"report_to":"cf-nel","max_age":604800}
CF-RAY: 5eeda297ffb90b78-AMS
Content-Encoding: gzip
我希望通过Nginx的端口80强制AJAX连接。是否可以评估:443的主机标头,如果存在,则将其更改为:80?如果是这样,完成这项任务最有效的方法是什么

顺便说一句。。。我已经实现了代理重定向https://http://;指令,该指令适用于URL,但不适用于主机头

谢谢你的帮助

恭敬地

加里

编辑:

我取得了一些更大的进步,当我将AJAX URL复制/粘贴到浏览器的地址栏时,MP3下载请求成功,MP3下载成功(与前面单击MP3下载链接时的示例相反)

有趣的是,复制/粘贴方法产生初始302响应,而单击链接方法产生200响应

复制/粘贴方法:

GET http://example.com/ajax/inc/283544 HTTP/1.1
Host: example.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=k6o4mq4np28bdr6n2g2pbgq190; zvAuth=1; zvLang=0; ZvcurrentVolume=100; nua=Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20Win64%3B%20x64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F86.0.4240.75%20Safari%2F537.36; asus_token=81G3BJcZjrt06SpsxUrh; _zvBoobs_=%2F%2F_-%29

HTTP/1.1 302 Found
Server: nginx/1.19.2
Date: Sun, 08 Nov 2020 14:27:53 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=d2f42248bc953328459ea277d77ee62671604845673; expires=Tue, 08-Dec-20 14:27:53 GMT; path=/; domain=.example.com; HttpOnly; SameSite=Lax; Secure
Location: http://example.com/download/283544
CF-Cache-Status: DYNAMIC
cf-request-id: 0649dab4e200000b6bce8a6000000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=SRYrhqPuwCUwe1MPbJ4RGW%2F8yqt4t8UD19zHwUrcNqX94%2FD8VZ6EW1vl2dogVCCaFkeDh3%2BCwogueN4i3K6Gc5SMenGqRg%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"report_to":"cf-nel","max_age":604800}
CF-RAY: 5eeffa349c0d0b6b-AMS
Content-Length: 0
Nginx访问日志(单击链接方法-失败):

Nginx访问日志(复制/粘贴方法-成功):

我可以用一双额外的眼睛来查看请求/响应和nginx访问日志,以确认我是否遗漏了什么

单击链接和复制/粘贴方法都要通过Nginx反向代理

非常感谢

加里

编辑:

我在Click Link 200 HTTP响应的主体中发现了以下内容:

192.168.0.154 - - [07/Nov/2020:10:25:22 +0000] "GET music.mp3 HTTP/1.1" 206 1982193 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36 Edg/86.0.622.38"
{"url":"https:\/\/example.com\/download\/2770587","isSuccess":1}
在我看来,这似乎是一个Nginx不知道的Javascript重定向,其中https协议没有被重写为http

Nginx是否可以评估响应主体并重写给定字符串(即https=>http)

我想我可以用GreaseMonkey之类的东西来验证我的理论

再次感谢您的时间和兴趣

恭敬地

加里

所有:

就这样!随后的异步AJAX调用使用一个Javascript重定向进行响应,该重定向使用Nginx的sub_filter指令进行了修正

        location / {
            resolver 103.86.99.100;
            proxy_bind $server_addr;
            proxy_pass https://$host$request_uri;
            proxy_redirect https:// http://;
            proxy_set_header Accept-Encoding ""; # Needed by sub_filter to disable gzip compression
            sub_filter_types text/javascript text/css text/xml;
            sub_filter 'https:' 'http:';
            sub_filter_once off;
        }
禁用gzip压缩、添加
sub\u filter\u types text/javascript
、创建
sub\u filter'https:''http:'
的组合重写了javascript重定向的协议

{"url":"http:\/\/z1.fm\/download\/3298838","isSuccess":1}
然后,我只需点击AJAX链接就可以下载MP3了

{"url":"https:\/\/example.com\/download\/2770587","isSuccess":1}
        location / {
            resolver 103.86.99.100;
            proxy_bind $server_addr;
            proxy_pass https://$host$request_uri;
            proxy_redirect https:// http://;
            proxy_set_header Accept-Encoding ""; # Needed by sub_filter to disable gzip compression
            sub_filter_types text/javascript text/css text/xml;
            sub_filter 'https:' 'http:';
            sub_filter_once off;
        }
{"url":"http:\/\/z1.fm\/download\/3298838","isSuccess":1}