CODEWITHSUNDEEP
onenote
Darren Beale
Darren Beale

Reputation: 773

OneNote API "Malformed multipart message"

I'm writing a library to to interact with the new OneNote API.

I can do the OAuth dance with LiveConnect no problem and am POSTing a simple multipart example to prove everything works before I start adding further attachments etc

Whatever I try I always get:

Content-Length: 48

{
  "Message": "Malformed multipart message"
}

The thing is, it isn't as far as I can tell.

I've gone through the request body character by character checking the headers against this document and it looks fine. I've also triple checked all the debugging suggestions in this document and I can't see what's wrong.

The raw request follows, is there something glaringly obvious I've missed?

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--

Upvotes: 1

Views: 478

Answers (2)

Darren Beale
Darren Beale

Reputation: 773

Thanks to @JamesLau-MSFT as he put me onto the right track.

Actually the boundary is fine. Playing with Apigee I can get it to post the exact content as specified above if there is a linebreak or some text after final boundary

You'll notice that the default OneNote example page in APIgee has a dot after the end boundary

This works:

--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

I'm no multipart expert but I did dig this up in the RFC:

The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:

 --gc0p4Jq0M2Yt08jU534c0p--

There appears to be room for additional information prior to the first encapsulation boundary and following the final boundary. These areas should generally be left blank, and implementations should ignore anything that appears before the first boundary or after the last one.

UPDATE:

The requirement for a line break after the final boundary appears to have been removed.

Upvotes: 1

JamesLau-MSFT
JamesLau-MSFT

Reputation: 284

I debugged a bit into this via the Apigee console. If you replace your part name "534a5a9ca709c" with something else (I used just "NewPart"), the request goes through successfully.

You should have been able to use "534a5a9ca709c" as the part name, so this appears to be a bug on our end. We will investigate into why it's happening, but in the meantime, you can use the workaround.

Update: This has nothing to do with the part name. As Darren pointed out, you need to make sure there is a new line after the ending part name (e.g. "--534a5a9ca709c--").

If you try this in the Apigee console, make sure you update the partname in both the message body as well as the header because they need to match.

- James (@jmslau)

Upvotes: 2

Related Questions