具有相同请求头的BASH cURL和PHP cURL的不同响应

这是一个非常有趣的问题

我正在为一个微型网络广播播放器编写一个API。为了获取当前曲目，我正在分析cast服务器前端

在SHOUTcast 1.x服务器的示例中，我能够解析URI

当我在FireFox中请求URI时，我会得到显示播放曲目列表的网页。如果我从承载API的服务器的BASH请求带有cURL的URI，我将得到该服务器的404

$curl-v-Ghttp://85.21.79.31:7128/played.html
*正在尝试85.21.79.31。。。
*连接到85.21.79.31（85.21.79.31）端口7128（0）
>GET/play.html HTTP/1.1
>主持人：85.21.79.31:7128
>用户代理：curl/7.47.0
>接受：*/*
> 
未找到ICY 404资源
icy-notice1:
SHOUTcast分布式网络音频服务器/Linux v1.9.8

icy-notice2:未找到请求的资源

*0到主机85.21.79.31的连接保持不变

我假设一个合适的用户代理可以帮助并添加

Mozilla

来接收该网页。那就行了

$curl-v-A“Mozilla”-Ghttp://85.21.79.31:7128/played.html
*正在尝试85.21.79.31。。。
*连接到85.21.79.31（85.21.79.31）端口7128（0）
>GET/play.html HTTP/1.1
>主持人：85.21.79.31:7128
>用户代理：Mozilla
>接受：*/*
> 
*HTTP 1.0，假设在正文之后关闭

根据我的发现，我将请求转移到我的PHP cURL实现中

$curlHandler=curl_init（）；
curl_setopt_数组(
$curlHandler，
[
CURLINFO_HEADER_OUT=>true，
CURLOPT_URL=>'http://85.21.79.31:7128/played.html',
CURLOPT_CUSTOMREQUEST=>“GET”，
CURLOPT_USERAGENT=>“Mozilla”，
CURLOPT_RETURNTRANSFER=>true，
CURLOPT_头=>false，
CURLOPT_NOBODY=>真
]
);
$response=curl\u exec（$curlHandler）；
$info=curl\u getinfo（$curlHandler）；
curl_close（$curlHandler）；
var_dump（$info）；
var_dump（$response）；

但我得到了404的回复

array(31) {
  ["request_header"]=>
  string(87) "GET /played.html HTTP/1.1
Host: 85.21.79.31:7128
User-Agent: Mozilla
Accept: */*

"
}

在比较请求头时，没有区别。所以我假设BASH和PHP的cURL实现之间存在差异，我看不到

那么这里发生了什么

更新（2019-07-31）

附加运行时环境信息

操作系统

PHP

更新（2019-07-31）

有关cURL的其他信息

猛击

$curl--版本
curl 7.47.0（x86_64-pc-linux-gnu）libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
协议：dict文件ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smb smtp smtps telnet tftp
功能：AsynchDNS IDN IPv6大文件GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

phpinfo（）

---

这是我自己的一大过错

首先，我在代码中留下了

CURLOPT_NOBODY=>true

（参见问题），这导致了一个空的回答

array(31) {
  ["request_header"]=>
  string(87) "GET /played.html HTTP/1.1
Host: 85.21.79.31:7128
User-Agent: Mozilla
Accept: */*

"
}

第二，我在代码中留下了

file\u get\u contents（$uri）

，这导致了问题中发布的警告

---

总之，在删除这两个cURL时，效果与预期一致。

尝试使用不同的用户代理，如

Mozilla/5.0（X11；Linux x86_64；rv:10.0）Gecko/20100101 Firefox/10.0

发布输出。响应与404相同。我已经试过了。但是，一般来说，通过进一步的BASH测试没有假设这会导致不同的响应。为了澄清我的问题，我添加了有关运行时环境的信息。我在第一次发布CLI版本时修复了PHP版本，该版本与FAST-CGI模块版本不同。当使用

PHP:7.3.7-fpm

：

[“http_code”]=>int（200）

@BenjaminW在docker容器上运行时，您的代码对我来说运行良好。我改变了问题，另外还提供了底层cURL的OS和PHP版本的信息。

Linux hostname 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 (2019-06-19) x86_64 GNU/Linux

PHP Version 7.3.7-2+0~20190725.42+debian9~1.gbp848ca5

cURL support     | enabled
cURL Information | 7.52.1
Age              | 3

Features

AsynchDNS        | Yes
CharConv         | No
Debug            | No
GSS-Negotiate    | No
IDN              | Yes
IPv6             | Yes
krb4             | No
Largefile        | Yes
libz             | Yes
NTLM             | Yes
NTLMWB           | Yes
SPNEGO           | Yes
SSL              | Yes
SSPI             | No
TLS-SRP          | Yes
HTTP2            | Yes
GSSAPI           | Yes
KERBEROS5        | Yes
UNIX_SOCKETS     | Yes
PSL              | Yes
HTTPS_PROXY      | Yes
Protocols        | dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtmp, rtsp, scp, sftp, smb, smbs, smtp, smtps, telnet, tftp
Host             | x86_64-pc-linux-gnu
SSL Version      | OpenSSL/1.0.2s
ZLib Version     | 1.2.8
libSSH Version   | libssh2/1.7.0


Directive   | Local Value | Master Value
curl.cainfo | no value    | no value