WireMock(Docker)获取Zip响应体积异常增大且文件无效问题排查

问题场景 #

我们在CI/CD环境中通过以下Dockerfile构建WireMock容器：

FROM wiremock/wiremock:latest
COPY wiremock /home/wiremock
ENTRYPOINT ["/docker-entrypoint.sh", "--global-response-templating", "--verbose"]

将Zip文件复制到容器后，配置的响应头包含：

• Content-Type: application/zip 或 application/octet-stream
• Content-Disposition: attachment; filename=extract.zip
• Content-Length: 2094
  但实际获取到的文件大小为3644，且不是有效的Zip文件。

原因分析 #

1. 默认Gzip压缩干扰：WireMock默认会对响应启用Gzip压缩，返回的是压缩后的二进制内容，但你配置的Content-Length是原文件的大小。如果客户端没有正确识别Content-Encoding: gzip头并解压，就会把压缩后的内容当成原始文件，导致大小不符且文件无效。
2. 文件复制异常：复制到容器的Zip文件可能在构建过程中损坏，或是被错误地以文本模式处理，破坏了二进制结构。
3. 响应映射配置错误：如果在WireMock的映射文件中用body字段直接引用文件内容，而非bodyFileName，会导致二进制文件被当作字符串解析，损坏文件结构。

解决方案 #

1. 禁用Gzip压缩 #

在ENTRYPOINT中添加--disable-gzip参数，确保响应不被压缩，与你设置的Content-Length匹配。修改后的Dockerfile：

FROM wiremock/wiremock:latest
COPY wiremock /home/wiremock
ENTRYPOINT ["/docker-entrypoint.sh", "--global-response-templating", "--verbose", "--disable-gzip"]

2. 确保文件正确复制 #

使用COPY命令时显式设置文件权限，避免因权限问题导致读取异常，同时确保文件以二进制模式复制（Docker默认是二进制模式，但显式配置更稳妥）：

COPY --chmod=0644 wiremock /home/wiremock

3. 正确配置响应映射 #

在WireMock的映射文件（如mappings/download.json）中，用bodyFileName指定Zip文件路径，不要直接用body字段。示例映射：

{
  "request": {
    "method": "GET",
    "url": "/download/extract.zip"
  },
  "response": {
    "status": 200,
    "headers": {
      "Content-Type": "application/zip",
      "Content-Disposition": "attachment; filename=extract.zip",
      "Content-Length": "2094"
    },
    "bodyFileName": "extract.zip"
  }
}

注意：bodyFileName对应的文件需放在容器内的/home/wiremock/__files目录下，所以本地的Zip文件要放在wiremock/__files路径下，再通过COPY命令复制到容器。

4. 验证容器内文件完整性 #

进入容器检查文件大小和有效性，确认文件在复制过程中没有损坏：

# 替换<container-id>为你的容器ID
docker exec -it <container-id> bash
cd /home/wiremock/__files
# 查看文件大小是否和本地一致
ls -l extract.zip
# 测试Zip文件是否有效
unzip -t extract.zip

内容的提问来源于stack exchange，提问作者tm1701