0

To anyone stumbling upon this: this is in regard to the Pushbullet API, as tagged.

Trying this for the first time.

I seem to have a good response to my Upload Request, and I'm pretty sure I have the correct Upload URL for this, but the Upload stage keeps failing on me.

Code is VB6 using an MSXML2.XMLHTTP instance for sending:

With XMLHTTP
    .open "POST", UploadUrl, True
    .setRequestHeader "Access-Token", AccessToken
    .setRequestHeader "Content-Type", "multipart/form-data; boundary=" & ContentBoundary
    .onreadystatechange = Me
    .send MultipartFormBody
End With

MultipartFormBody is a Byte array so nothing is getting transcoded into UTF-8 there. ContentBoundary is a String generated in tandem with the body data. UploadUrl is a String with a value returned in the immediately prior (Upload Request) response. XMLHTTP creates a Content-Length header automagically.

As far as I can see the message body is properly formatted too. When I had a flaw in the latter I got back an error message that was quite helpful in correcting it.

--PushbulletReporter_3E43228zZz82234E3{CRLF}
Content-Disposition: form-data; name="file"; filename="capture.png"{CRLF}
Content-Type: image/png{CRLF}
{CRLF}
{bytes of a PNG image}--PushbulletReporter_3E43228zZz82234E3--{CRLF}

But now I get a 500 Internal Server Error with an error message "An unhandled server error occurred."

The body is a hair under 3.5KB. I'm down to notions like... perhaps chunked encoding is required here?

Any clues? What more information might help?

Bob77
  • 13,167
  • 1
  • 29
  • 37

1 Answers1

1

First I want to apologize for that file upload thing, multipart/form-data is regrettably hard to actually create since few languages have standard libraries that do this. I have a version where you just upload the bytes directly, but it's not quite ready to be released yet.

I see some "unexpected EOF" errors in the logs, so I can only assume that that is what is going on here. I haven't run any tests yet, but I think you don't have enough {CRLF}s in there or some other minor error. If you could create the encoded data with an existing library then compare it to your output, that would be ideal.

I'll try to make the server return a 400 in this case, but I imagine it will be "Invalid multipart body".

I made a test script, and it looks like the missing CRLFs is the problem:

--d3880c80febbef19d78c6daf83da33d6b973d2524d9a6146e4bc71f4973b\r\nContent-Disposition: form-data; name=\"file\"; filename=\"filename\"\r\nContent-Type: application/octet-stream\r\n\r\n{bytes of a PNG image}\r\n--d3880c80febbef19d78c6daf83da33d6b973d2524d9a6146e4bc71f4973b--\r\n

Note the CRLF after the bytes of the PNG image part, I think you are missing those

Chris Pushbullet
  • 1,039
  • 9
  • 10
  • I'll take a look at that, because it seems very plausible and this is the first time I've tried throwing this hand-rolled logic's multipart/form-data output at a real server. Perhaps I simply missed that CRLF when I pored over the relevant RFC. Thanks, I'll go squint at it and report back. – Bob77 Sep 22 '15 at 07:00
  • That was it! Thanks for figuring it out. I also ran into what seems to be a well known UrlMon (Microsoft, IE's HTTP/FTP transport layer stack) issue where a non-GET method receiving a `204 No Content` reports a status of `1223 Unknown` with the response headers unavailable. :( But easy enough to hack around. For all I know their WinHTTP stack has the same flaw (or feature?). – Bob77 Sep 22 '15 at 07:37
  • Unrelated FYI: Microsoft's HTTP stacks offer no WebSocket support to native code applications until Windows 8 where it seems to have been shoehorned into their WinHTTP library. So since many will stay on Win7 for years and won't move everything to .Net either, people would need 3rd party libraries for WebSocket support. – Bob77 Sep 22 '15 at 07:46
  • Ouch. Go go platforms. There's an undocumented (because it's more annoying to use) HTTP streaming endpoint: curl --no-buffer https://stream.pushbullet.com/streaming/ that you can try if you're able to read HTTP streaming responses. – Chris Pushbullet Sep 22 '15 at 21:03
  • Good to know about 204, I think I don't use 204 like anywhere except for this one call, so in the future people should not run into that issue. – Chris Pushbullet Sep 22 '15 at 21:04
  • I don't need streaming responses at present, though they're clearly important for more general use cases. Thanks for the alternative, though in the end it might just be easier to use a 3rd party HTTP library with broader support for current features. And thanks again for the clue above - I might have found it eventually but your answer got things moving for me again. – Bob77 Sep 22 '15 at 21:55
  • The server should return a 400 in this case now, at least. – Chris Pushbullet Sep 22 '15 at 22:37