在 Jetty 8 下运行的 Servlet 收到以下请求：
Header:
Content-Type = multipart/related; boundary=example
Data:
--example
content-type: text/xml; charset=UTF-8
data1here
--example
content-type: text/xml; charset=UTF-8
data2here
--example--
【问题讨论】：
Consume事件使用Apache CXF提供的JAX-RS注解：
@Consumes("multipart/related")
来自 JAX-RS 文档：
现在（从 2.2.5 开始）可以让注册的 JAX-RS MessageBodyReaders 读取单独的
multipart/form-data部分，对于multipart/mixed或multipart/related等类型已经可以做到这一点。
另见：
请注意，GlassFish 使用的 Jersey 在其 source code 中没有提及 related。
Google 为 HTTP client 提供了一个 API，它按照 RFC 解析 multipart/related 消息。
RESTeasy 项目可以通过 JAX-RS 解析 multipart/related 内容。
通过一些流扭曲，可以使用 JavaMail API 来解析 MimeMultipart 消息：
默认的多部分子类型是“混合”。其他多部分子类型，例如“alternative”、“related”等，可以作为 MimeMultipart 的子类实现，并带有其他方法来实现该类型多部分内容的附加语义。
JavaMail FAQ 提供了更多详细信息：
如上所述，还有更复杂的情况需要考虑。特别是，消息可能具有
multipart/mixed和multipart/alternative部分的任意嵌套，并且可能包括用于嵌入HTML 的multipart/related部分和用于安全消息的multipart/signed和/或multipart/encrypted部分。
我建议不要使用这种方法，因为它混合了隐喻（它将 MIME over HTTP/web 与 MIME over SMTP/mail 混为一谈）。也就是说，从概念上讲，JavaMail 用于通过 SMTP/IMAP 读取和写入消息，这可能会让未来的维护者想知道为什么 JavaMail 被用于解析通过 Servlet 接收的 MIME 消息，尤其是当有基于注释的解决方案可用时。也就是说，记录代码及其使用原因将是一种避免混淆的方法。
根据容器的不同，它可能会也可能不会处理所有相关的 RFC。您可能需要尝试（或仔细阅读）不同容器的源代码，才能了解哪些容器实现了此功能。
source code 有几个与解析输入流相关的地方，仅限于multipart/form-data：
此外，unit tests 不包括 RFC 2387，这是一个强有力的指标，表明容器不处理 Servlet 3.0 API 下的 related 部分。因此，JAX-RS 可能是最好的方法。
Tomcat 将 not implemented multipart/related 作为 Servlet 3.0 规范的一部分，尽管存在 Tomcat 7.0.47 的修补版本。
【讨论】：
您可以使用 JavaMail 库并将数据作为“邮件”读取。您最终会得到一个 MimeMessage，并且可以通过 BodyParts 进行处理。用法很简单，我使用这种方法来实现 AS2 服务器，并且我看到其他 AS2 实现也这样做，所以这是一种很常见的方法。
我认为这里没有标准冲突。整个请求格式是 MIME，因此在我看来，由一个用于处理 MIME 编码消息的库来处理它是一种正确的处理方式。
【讨论】：