Jetty 12嵌入式代理服务器文件上传流失效问题求助

1. Servlet 6规范与Jetty 12流处理逻辑变更：Jetty 12基于Servlet 6，HttpServletRequest的Part.getInputStream()返回的是单次消费型流——一旦被读取（哪怕是解析Part元数据时的内部读取操作），流指针会直接移动到末尾，且Servlet容器可能自动关闭该流。而Jetty 12的InputStreamRequestContent和MultiPartRequestContent不会自动缓存或重置流状态，直接传入已消费的流会导致下游服务读取时触发EOF异常。
2. 多部分内容处理机制差异：Jetty 11的MultiPartContentProvider支持从已解析的Part流构建转发内容，但Jetty 12的MultiPartRequestContent更依赖原始请求体的完整可重复读取能力。当你先解析Part再传递流时，原始请求体已经被Servlet API消费，无法重复读取。

• 复用原始请求体流（推荐，零内存开销）：
  跳过Part解析环节，直接将原始请求体的InputStream传入MultiPartRequestContent，避免Part流被消费的问题。代码示例：

  // 获取未被Part解析消费的原始请求体流
  InputStream rawRequestStream = request.getInputStream();
  // 直接用原始流构建多部分转发内容
  MultiPartRequestContent forwardContent = new MultiPartRequestContent(rawRequestStream, request.getContentType());
  // 构建下游请求并发送
  

  注意：如果需要提前获取文件名等Part元数据，这种方式不适用，需使用下面的缓存方案。

• 使用Jetty CachedRequestContent缓存请求体：
  用Jetty内置的CachedRequestContent将原始请求体缓存到内存或临时文件（自动根据内容大小切换，默认阈值为2MB），既可以解析Part元数据，又能重复读取流用于转发。代码示例：

  // 缓存原始请求体，自动处理内存/临时文件存储
  CachedRequestContent cachedContent = new CachedRequestContent(request.getInputStream());
  
  // 从缓存流手动解析Part（使用Jetty的MultiPartParser）
  MultiPartParser parser = new MultiPartParser(cachedContent.getInputStream(), request.getContentType());
  Part part = parser.nextPart();
  // 处理Part元数据（如文件名）...
  
  // 重置缓存流指针到开头，用于构建下游请求内容
  cachedContent.reset();
  MultiPartRequestContent forwardContent = new MultiPartRequestContent(cachedContent.getInputStream(), request.getContentType());
  

  这种方式既满足Part解析需求，又避免了全量内存占用的问题。

• 禁用Spring自动Multipart解析：
  确保Spring Boot不会提前消费请求体，在application.properties中添加配置：

  spring.servlet.multipart.enabled=false
  

  防止Spring的MultipartResolver提前解析请求体导致原始流被消费。

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