如何完全中止输出流下载？

Question

我们目前正在开发一项服务，该服务将归档数据并将其以ZipOutputStream 的形式返回给用户。我们目前正在寻找的是在服务器端出现问题时完全终止操作的选项。对于我们当前的实现（仅关闭响应输出流），错误会导致用户端的 zip 格式错误，但在尝试解压缩之前无法判断存档是否格式错误。期望的行为类似于下载终止（例如，从浏览器的角度来看，它会导致下载不成功的指示（红十字图标或类似的东西，取决于浏览器）明确告诉用户出现问题）。我们正在使用 Spring Boot，因此任何 Java 代码示例都将不胜感激，但如果您知道负责这种行为的底层 HTTP 机制，并且可以指出正确的方向，那也将不胜感激. 这是我们目前所拥有的（输出是 Spring REST 控制器的响应输出流 (HttpServletResponse.getOutputStream())：

try (ZipOutputStream zipOutputStream = new ZipOutputStream(outputStream)) {
    try {
        for (ZipRecordFile fileInfo : zipRecord.listZipFileOverride()) {
            InputStream fileStream = getFileStream(fileInfo.s3region(), fileInfo.s3bucket(),
            fileInfo.s3key());
            ZipEntry zipEntry = new ZipEntry(fileInfo.fileName());
            zipOutputStream.putNextEntry(zipEntry);
            fileStream.transferTo(zipOutputStream);
        }
    }
    catch (Exception e) {
        outputStream.close();
    }
}

Answer 1

没有一种（干净的）方法可以做你想做的事：

一旦您开始将 ZIP 文件写入输出流，再更改 HTTP 响应代码为时已晚。响应代码在响应开始时发送。

因此，HTTP 服务器没有适当的方法告诉 HTTP 客户端：“嘿...忽略我发送给你的 ZIP 文件，因为它已损坏”。

那么有什么替代品呢？

1. 在服务器端，将整个 ZIP 创建为内存对象或将其写入临时文件。如果成功，请发送 2xx 响应，后跟 ZIP 数据。如果失败，请发送 4xx 或 5xx 响应。

   主要问题是您需要足够的内存或文件系统空间来保存 ZIP 文件。

2. 重新设计您的 HTTP API，以便客户端可以发送第二个请求以检查第一个请求的响应是否包含完整的 ZIP 文件。

3. 您也许可以利用 MIME 多部分编码；见RFC 1341。格式良好的 MIME 多部分的每个部分都有一个开始标记和一个结束标记。您可以尝试的是让您的网络应用“手动”构建包含 ZIP 的多部分流。如果它决定必须中止 ZIP，它可以直接关闭输出流而不添加所需的结束标记。

   这样做的主要问题是您依赖客户端上的 HTTP 堆栈来告诉浏览器（或其他）多部分已损坏。此外，浏览器（或其他）不得将部分（即损坏的）ZIP 文件传递​​给用户。我不确定您是否可以依靠（特定的）网络浏览器来做到这一点。

4. 如果您在客户端通过自定义代码运行下载，您可以实现自己的封装协议。效果与 3 相同……但您不会滥用 MIME 规范。