OneNote API“格式错误的多部分消息”答案

【问题标题】：OneNote API "Malformed multipart message"OneNote API“格式错误的多部分消息”
【发布时间】：2014-04-13 10:06:36
【问题描述】：

我正在编写一个库来与新的 OneNote API 交互。

在我开始添加更多附件等之前，我可以使用 LiveConnect 进行 OAuth 舞蹈，并且正在发布一个简单的多部分示例以证明一切正常

无论我尝试什么，我总能得到：

Content-Length: 48

{
  "Message": "Malformed multipart message"
}

问题是，我无法判断。

我已经逐个字符地检查了请求正文字符，并对照this document 检查了标题，它看起来很好。我还三次检查了this document 中的所有调试建议，但我看不出有什么问题。

我已经对 HTML UTF-8 进行了编码
我正在使用库来构建主体，并且通过了可视化解析（见下文）
我发帖到https://www.onenote.com/api/v1.0/pages
标题看起来不错，边界、内容类型等也不错。

原始请求如下，我错过了什么明显的东西吗？

POST /api/v1.0/pages HTTP/1.1
Host: www.onenote.com
User-Agent: {myLibrary}
Authorization: Bearer {mytoken}
Content-Length: 416
Content-Type: multipart/form-data; boundary=534a5a9ca709c

--534a5a9ca709c
Content-Type: text/html
Content-Disposition: form-data; name="Presentation"

<!DOCTYPE html>
        <html>
          <head>
            <title>onenote test page</title>
            <meta name="created" content="2014-04-13T10:36:28+01:00"/>
          </head>
          <body>
            <p>Hello OneNote World</p>
          </body>
        </html>
--534a5a9ca709c--

【问题讨论】：

标签： onenote

【解决方案1】：

我通过Apigee console对此进行了一些调试。如果您将零件名称“534a5a9ca709c”替换为其他名称（我只使用了“NewPart”），则请求会成功通过。

您应该能够使用“534a5a9ca709c”作为部件名称，所以这似乎是我们这边的一个错误。我们将调查发生这种情况的原因，但与此同时，您可以使用解决方法。

更新：这与零件名称无关。正如 Darren 指出的那样，您需要确保在结束部分名称之后有一个新行（例如“--534a5a9ca709c--”）。

如果您在 Apigee console 中尝试此操作，请确保更新消息正文和标头中的部分名称，因为它们需要匹配。

- 詹姆斯 (@jmslau)

【讨论】：

您对为什么在最终分隔符之后需要内容有任何更新吗？这对我来说似乎是不标准的行为。

【解决方案2】：

感谢@JamesLau-MSFT，他让我走上了正轨。

其实边界是好的。使用 Apigee 我可以让它发布上面指定的确切内容如果在最终边界之后有换行符或一些文本

您会注意到 APIgee 中默认的 OneNote 示例页面在结束边界后有一个点

这行得通：

--534a5a9ca709c
Content-Type: text/html
Content-Disposition: form-data; name="Presentation"

<!DOCTYPE html>
        <html>
          <head>
            <title>onenote test page</title>
            <meta name="created" content="2014-04-13T10:36:28+01:00"/>
          </head>
          <body>
            <p>Hello OneNote World</p>
          </body>
        </html>
--534a5a9ca709c--
Blah Blah

我不是多部分专家，但我确实在 the RFC 中挖掘了这个：

最后一个主体部分之后的封装边界是可区分的分隔符，表示不会有更多的身体部位跟随。这样的定界符与前面的定界符相同，具有在行尾添加两个连字符：
 --gc0p4Jq0M2Yt08jU534c0p--  
在第一个封装边界和跟随最后的边界。这些区域一般应该留下空白，并且实现应该忽略之前出现的任何内容第一个边界或最后一个边界之后。

更新：

最终边界后换行的要求似乎已被删除。

【讨论】：