英文:

Spring boot or maven corrupts binary files, only in production

问题

在我所工作的项目中，存在一个问题，即使用 Spring Boot 从 webjar 文件中提供的二进制静态文件（woff2 和 wasm 文件）在一个 Spring Boot 项目中进行服务时会出现损坏的问题，它们的大小比应该的要大。

当在本地使用 mvn spring-boot:run 运行服务时，文件大小是正确的，运行良好，但在生产环境中无法使用这些字体和 Web Assembly 代码。如果我从 jar 文件中提取 wasm 文件，它的大小为 196287 字节，这与开发文件系统/存储库中的大小完全相同。但在生产环境中，下载文件的大小为 225201 字节，它将无法编译 Web Assembly 模块。

我看到了一些与 Maven 损坏文件相关的问题，但由于当我提取文件时文件大小是正确的，可能还有其他原因？我们一直在使用版本为 3.0.1 的 maven-resources-plugin，这有点过时。我们正在尝试根据 https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html 中描述的方式禁用二进制类型的过滤。

<build>
  <resources>
    <resource>
      <directory>build</directory>
      <targetPath>META-INF/resources</targetPath>
    </resource>
  </resources>
  <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-resources-plugin</artifactId>
       <version>3.0.1</version>
       <configuration>
          <encoding>UTF-8</encoding>
          <nonFilteredFileExtensions>
              <nonFilteredFileExtension>ttf</nonFilteredFileExtension>
              <nonFilteredFileExtension>woff</nonFilteredFileExtension>
              <nonFilteredFileExtension>woff2</nonFilteredFileExtension>
              <nonFilteredFileExtension>eot</nonFilteredFileExtension>
              <nonFilteredFileExtension>wasm</nonFilteredFileExtension>            
         </nonFilteredFileExtensions>
       </configuration>
     </plugin>
  </plugins>
</build>

我在考虑，如果 Spring Boot 在开发模式下实际上读取文件的 MIME 类型，并在生产环境中假定所有内容都是 UTF-8 文本，从而损坏二进制文件？这应该是许多项目共有的问题吧？

对于如何进一步调试此问题，您有什么想法吗？

更新：下面附上文件差异的第一个点（来自 vbindiff），我对此并不是很了解，但也许其他人可以看出些什么。

pulldown_cmark_wasm_bg.wasm                                                                                                                                                                                                     
0000 0190: 06 89 80 80 80 00 01 7F  01 41 80 80 C0 00 0B 07  ........ .A......                                                                                                                                                  

...（此处省略）

0000 02F0: AC 01 D8 01 53 D9 01 B3  01 40 82 01 DA 01 DB 01  ....S... .@......                                                                                                                                                  

...（此处省略）

0000 0310: 92 01 D0 01 38 CF 01 AA  01 D5 01 87 01 D4 01 86  ....8... ........                                                                                                                                                  

pulldown_cmark_wasm_bg.wasm-corrupt                                                                                                                                                                                             
0000 0190: BF BD EF BF BD EF BF BD  EF BF BD 00 01 70 01 3F  ........ .....p.?                                                                                                                                                  

...（此处省略）

0000 02F0: EF BF BD 01 EF BF BD 01  EF BF BD 01 17 EF BF BD  ........ ........                                                                                                                                                  

...（此处省略）

0000 0310: EF BF BD 01 EF BF BD 01  EF BF BD 01 40 82 01 DA  ........ ......@...                                                                                                                                                  

箭头键移动，F 查找，RET 下一个差异，ESC 退出，T 移动到顶部，C ASCII/EBCDIC，E 编辑文件，G 转到位置，Q 退出，B 移动到底部。

<details>
<summary>英文:</summary>

In a project I work in here is a problem with binary static files (woff2 and wasm files) served with a Spring boot project from a webjar file are being corrupted, they are larger than they should be.

When the service is ran locally with mvn spring-boot:run the file size is correct and works fine, but in production the fonts and Web Assembly code cannot be used. The wasm file is 196287 bytes if I extract it from the jar file and that is exactly the same as in the development filesystem/repo. When served in production the file size of the downloaded file is 225201 and it will not compile the Web Assembly module.

I have seen several other issues related to maven corrupting files, but as the file size is correct when I extract the file possibly this is something else? We have been using maven-resources-plugin version 3.0.1 which is a bit outdated. We are trying to disabling filtering for binary types as described in https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html .

<build>
<resources>
<resource>
<directory>build</directory>
<targetPath>META-INF/resources</targetPath>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<encoding>UTF-8</encoding>
<nonFilteredFileExtensions>
<nonFilteredFileExtension>ttf</nonFilteredFileExtension>
<nonFilteredFileExtension>woff</nonFilteredFileExtension>
<nonFilteredFileExtension>woff2</nonFilteredFileExtension>
<nonFilteredFileExtension>eot</nonFilteredFileExtension>
<nonFilteredFileExtension>wasm</nonFilteredFileExtension>
</nonFilteredFileExtensions>
</configuration>
</plugin>
</plugins>
</build>

I'm thinking if Spring boot when in dev mode actually reads the mime type of a file and in production assumes everything is UTF-8 text, thereby corrupting the binary files? This should then be a common problem for may projects?

Any thoughts on how to debug this further?

Update: Attached below is the first point where the files differ (from vbindiff), it's a bit beyond my skills to read anything out of this but maybe someone else can.

pulldown_cmark_wasm_bg.wasm
0000 0190: 06 89 80 80 80 00 01 7F 01 41 80 80 C0 00 0B 07 ........ .A......
0000 01A0: D1 80 80 80 00 05 06 6D 65 6D 6F 72 79 02 00 06 .......m emory...
0000 01B0: 66 6F 72 6D 61 74 00 32 11 5F 5F 77 62 69 6E 64 format.2 .wbind
0000 01C0: 67 65 6E 5F 6D 61 6C 6C 6F 63 00 9C 01 12 5F 5F gen_mall oc....
0000 01D0: 77 62 69 6E 64 67 65 6E 5F 72 65 61 6C 6C 6F 63 wbindgen _realloc
0000 01E0: 00 A1 01 0F 5F 5F 77 62 69 6E 64 67 65 6E 5F 66 ....__wb indgen_f
0000 01F0: 72 65 65 00 B4 01 09 F4 80 80 80 00 01 00 41 01 ree..... ......A.
0000 0200: 0B 3E B5 01 B6 01 08 B9 01 B2 01 7B 29 B1 01 D6 .>...... ...{)...
0000 0210: 01 80 01 95 01 97 01 1F CB 01 C8 01 CD 01 26 4D ........ ......&M
0000 0220: 83 01 CC 01 BA 01 BB 01 81 01 BC 01 37 47 CE 01 ........ ....7G..
0000 0230: 92 01 D0 01 38 CF 01 AA 01 D5 01 87 01 D4 01 86 ....8... ........
0000 0240: 01 D3 01 94 01 D2 01 39 D1 01 85 01 A0 01 D7 01 .......9 ........
0000 0250: AC 01 D8 01 53 D9 01 B3 01 40 82 01 DA 01 DB 01 ....S... .@......
0000 0260: CA 01 DC 01 8B 01 DD 01 17 B0 01 11 BD 01 AE 01 ........ ........
0000 0270: 0A CC 8E 87 80 00 DE 01 D0 7A 02 2E 7F 03 7E 23 ........ .z....~#
0000 0280: 00 41 D0 04 6B 22 03 24 00 02 40 02 40 02 40 20 .A..k".$ ..@.@.@
0000 0290: 02 41 05 76 22 04 41 80 01 20 04 41 80 01 4B 1B .A.v".A. . .A..K.
0000 02A0: 22 05 41 05 74 22 06 41 7F 4C 0D 00 02 40 20 06 ".A.t".A .L...@ .
0000 02B0: 41 08 10 BE 01 22 04 45 0D 00 20 04 42 00 37 03 A....".E .. .B.7.
0000 02C0: 10 20 04 41 20 3A 00 00 20 04 41 18 6A 42 00 37 . .A :.. .A.jB.7
0000 02D0: 03 00 20 03 41 F0 01 6A 41 AC BD C0 00 10 8C 01 .. .A..j A.......
0000 02E0: 20 03 29 03 F8 01 21 31 20 03 29 03 F0 01 21 32 .)...!1 .)...!2
0000 02F0: 02 40 41 80 1C 41 04 10 BE 01 22 06 45 0D 00 20 .@A..A.. ..".E..
0000 0300: 03 41 80 02 6A 41 F0 00 6A 42 80 80 80 80 20 37 .A..jA.. jB.... 7
0000 0310: 03 00 20 03 41 E8 02 6A 42 00 37 03 00 20 03 41 .. .A..j B.7.. .A
pulldown_cmark_wasm_bg.wasm-corrupt
0000 0190: BF BD EF BF BD EF BF BD EF BF BD 00 01 70 01 3F ........ .....p.?
0000 01A0: 3F 05 EF BF BD EF BF BD EF BF BD EF BF BD 00 01 ?....... ........
0000 01B0: 00 11 06 EF BF BD EF BF BD EF BF BD EF BF BD 00 ........ ........
0000 01C0: 01 7F 01 41 EF BF BD EF BF BD EF BF BD 00 0B 07 ...A.... ........
0000 01D0: D1 80 EF BF BD EF BF BD 00 05 06 6D 65 6D 6F 72 ........ ...memor
0000 01E0: 79 02 00 06 66 6F 72 6D 61 74 00 32 11 5F 5F 77 y...form at.2._w
0000 01F0: 62 69 6E 64 67 65 6E 5F 6D 61 6C 6C 6F 63 00 EF bindgen malloc..
0000 0200: BF BD 01 12 5F 5F 77 62 69 6E 64 67 65 6E 5F 72 ....__wb indgen_r
0000 0210: 65 61 6C 6C 6F 63 00 EF BF BD 01 0F 5F 5F 77 62 ealloc.. ....__wb
0000 0220: 69 6E 64 67 65 6E 5F 66 72 65 65 00 EF BF BD 01 indgen_f ree.....
0000 0230: 09 F4 80 80 80 00 01 00 41 01 0B 3E EF BF BD 01 ........ A..>....
0000 0240: EF BF BD 01 08 EF BF BD 01 EF BF BD 01 7B 29 EF ........ .....{).
0000 0250: BF BD 01 EF BF BD 01 EF BF BD 01 EF BF BD 01 EF ........ ........
0000 0260: BF BD 01 1F EF BF BD 01 EF BF BD 01 EF BF BD 01 ........ ........
0000 0270: 26 4D EF BF BD 01 EF BF BD 01 EF BF BD 01 EF BF &M...... ........
0000 0280: BD 01 EF BF BD 01 EF BF BD 01 37 47 EF BF BD 01 ........ ..7G....
0000 0290: EF BF BD 01 EF BF BD 01 38 EF BF BD 01 EF BF BD ........ 8.......
0000 02A0: 01 EF BF BD 01 EF BF BD 01 EF BF BD 01 EF BF BD ........ ........
0000 02B0: 01 EF BF BD 01 EF BF BD 01 EF BF BD 01 39 EF BF ........ .....9..
0000 02C0: BD 01 EF BF BD 01 EF BF BD 01 EF BF BD 01 EF BF ........ ........
0000 02D0: BD 01 EF BF BD 01 53 EF BF BD 01 EF BF BD 01 40 ......S. .......@
0000 02E0: EF BF BD 01 EF BF BD 01 EF BF BD 01 EF BF BD 01 ........ ........
0000 02F0: EF BF BD 01 EF BF BD 01 EF BF BD 01 17 EF BF BD ........ ........
0000 0300: 01 11 EF BF BD 01 EF BF BD 01 0A CC 8E EF BF BD ........ ........
0000 0310: EF BF BD 00 EF BF BD 01 EF BF BD 7A 02 2E 7F 03 ........ ...z....
┌──────────────────────────────────────────────────────────────────────────────┐
│Arrow keys move F find RET next difference ESC quit T move top │
│C ASCII/EBCDIC E edit file G goto position Q quit B move bottom │
└──────────────────────────────────────────────────────────────────────────────┘

</details>


# 答案1
**得分**: 1

也许针对这些二进制文件启用了过滤器，在生产构建中它可能错误地替换了一些二进制文件中的数据。

也许尝试运行diff命令来比较这些二进制文件中发生了什么变化？

<details>
<summary>英文:</summary>

Maybe filtering is enabled for those binary files and in prod build it does replace by mistake some data in binary files. 

Maybe try to run diff to compare what has changed in those binary files?

</details>



# 答案2
**得分**: 0

似乎问题出在Nginx反向代理和结合创建的Spring Boot服务的头部组合上。Node.js服务没有相同的问题。

我不确定问题最终是如何解决的，可能问题中缺少一些信息，所以我现在将关闭这个问题。

<details>
<summary>英文:</summary>

It seems that the problem was a combination of the headers that the Nginx reverse proxy in front and the Spring Boot service created in combination. The Node.js services did not have the same problem.

I&#39;m not sure how this was eventually solved and probably some information was missing in the question so I&#39;ll close this question now.

</details>