好的，这很奇怪，我可以通过摆脱空间来修复它，但是发生了什么？
我的网站上有两个文件，AAAy H.mp3和AAAy L.mp3。我可以很好地浏览它们。
当我这样做时：
curl "http://mikehelland.com/omg/AAAy L.mp3"
我收到了mp3文件。
当我这样做时：
curl "http://mikehelland.com/omg/AAAy H.mp3"
我得到400，请求不好。也在做：
curl "http://mikehelland.com/omg/AAAY H.mp3"
产生400。
将H更改为L或A或M或其他任何似乎都可以正常工作。发生了什么事？
答案 0 :(得分：0)
这是因为服务器如何解释文件名中的空格，尝试将其替换为％20（表示url中的空格符号），如下所示：
卷曲“http://mikehelland.com/omg/AAAy%20H.mp3”
如果您尝试使用浏览器访问文件并打开开发人员控制台，您会发现浏览器会在GET请求中插入此％20。所以这就是为什么你可以用浏览器访问文件，而不是从终端访问文件的原因。
另外，尝试在curl命令中添加--verbose选项。我注意到当你访问一些没有名字空格的不存在的文件时，响应是'Server：Apache / 2'的字段，但是当你添加空格时它是'Server：nginx'。
因此，当服务器停止处理requset时可能存在特殊情况，因为它无法区分如何处理请求中的第一行
GET /omg/AAAy H.mp3 HTTP/1.1
因为它希望在 / omg / AAAy 之后 HTTP / 1.1 ，而不是奇怪的 H.mp3 。也许服务器在解析HTTP时查看“H.mp3”中的第一个符号，并使事情破碎。所以我认为“/ omg / AAAy H.mp3”不起作用的原因，但“/ omg / AAAy L.mp3”的工作原理是由于服务器的解析机制。当然，没有％20，所有变种都是标准禁止的。