自APE's mod_xsendfile does not work with CF9's jrun_iis6_wildcard.dll以来，我使用<cfcontent>安全地提供服务文件。现在的问题是，如果文件下载很大，或者连接速度很慢，它会在很长一段时间内占用CF请求。如果没有办法强制实施硬限制，理论上可以将CF服务器与服务文件捆绑在一起。
我尝试在<cfcontent file="">下面做额外的日志记录/逻辑，但我注意到它们永远不会被触及并执行。
<cfcontent file="test.mp3">
<!--- won't reach here --->
<cfdump output="console" var="#now()# download done!">
通过处理太多的cfcontent请求，可以做些什么来避免CF被降低？
更新：好消息！ CF10 works with APE's mod_xsendfile！
答案 0 :(得分：0)
解决方案1
考虑到由于无法控制的因素（线程被“卡住”，服务/服务器关闭等），你不太可能拥有100％真实会计，你可以做到以下几点：
如果您只想跟踪总请求，可以使用在开始提供文件时递增的应用程序变量。然后，当内容完成后，您将减少计数。但是，您需要注意使用cflock以确保此更新不会导致任何问题。
如果你想将它记录到一个文件中，你可以做同样的事情，但仍然将它包装在cflock中，以确保你不会遇到任何与请求同时读/写文件的问题。
如果你正在使用SQL，你可以创建一个表来表示文件，并为每个fetch添加一条记录和相应的信息
使用返回的标识cfcontent文件，然后在完成时对具有指定ID的表进行更新，并使用正确的日期/时间和状态“success”并完成为yes。
在onerror期间，您可以更新表以反映状态“错误[相关错误详细信息]”并完成为1.添加一个catchall更新以更改为completed = 1或清除记录并不是一个坏主意不可用的（可能在启动时或在一段时间后申请）
这将允许您查询此表以查找当前待处理的总请求（以及它们是什么等）
但是，这只解决了长时间运行的请求的问题。
解决方案2
理想情况下，问题是安全地返回文件内容。根据文件的敏感程度（例如，首选私有但不是世界末日），您可以将它们“复制”到适当的Web可访问目录，但使用UUID作为名称。因此，假设您使用cfdirectory创建一个目录，然后将文件复制到其中，这就是Secret1.pdf。给你这样的东西：
/files/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx/Secret1.pdf然后执行a重定向到该目录。
然后，您可以设置计划任务或网关或您希望清除超过设定小时数的目录的任何方法。例如。例如，从现在起30分钟后删除目录xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx及其所有文件。