Why is a media upload breaking my app assocation (in firefox)? - google-drive-api
My javascript app creates a file and then uploads the media content. In Chrome, everything is hunky dorey. In Firefox, the act of uploading media is somehow breaking the association Drive holds between the file and my app, such that the icon is no longer my application icon (it's the default Google blue box) and clicking to open the file gives an error page.
So the steps are ...
Create the file (POST to /files)
Observe in Drive that the file exists and is displayed with my application icon
Upload the file contents (PUT with uploadType=media and convert=false)
Observe in Drive that the file's icon is now the Google blue
If I do exactly the same in Chrome, at step 4, the file is still associated with my app and displays my app icon.
Here is the media PUT from Chrome (ie the working one)
PUT https://content.googleapis.com/upload/drive/v2/files/0B6B-RNrxsCu2SERMMEFXMkdiOWM?uploadType=media&convert=false&useContentAsIndexableText=true&key=AIzaSyCt2bxTnrxo_IGvSUCBBAN_-29HJnzX_MU HTTP/1.1
:host: content.googleapis.com
x-origin: http://foo.myapp.appspot.com
x-javascript-user-agent: google-api-javascript-client/1.1.0-beta
x-goog-encode-response-if-executable: base64
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
accept-language: en-US,en;q=0.8,en-AU;q=0.6
authorization: Bearer ya29.AHES6ZQq1wAGltlEsnGKr6Dgtgkvp4zHCJsNTrXohnqrRmm3Ji8Yb14
x-referer: http://foo.myapp.appspot.com
x-clientdetails: appVersion=5.0%20(X11%3B%20Linux%20x86_64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F28.0.1500.95%20Safari%2F537.36&platform=Linux%20x86_64&userAgent=Mozilla%2F5.0%20(X11%3B%20Linux%20x86_64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F28.0.1500.95%20Safari%2F537.36
referer: https://content.googleapis.com/static/proxy.html?jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.en.l49lMhuyXyk.O%2Fm%3D__features__%2Fam%3DEQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAItRSTOvD2NxxPLz0HiGHMXTek7IhOVTHg
content-length: 9
:version: HTTP/1.1
origin: https://content.googleapis.com
accept-encoding: gzip,deflate,sdch
:path: /upload/drive/v2/files/0B6B-RNrxsCu2SERMMEFXMkdiOWM?uploadType=media&convert=false&useContentAsIndexableText=true&key=AIzaSyCt1bxTnrxo_IGvSUCBBAN_-29HJnzX_MU
content-type: text/html
accept: */*
:scheme: https
:method: PUT
Query String
uploadType=media
&convert=false
&useContentAsIndexableText=true
&key=AIzaSyCt2bxTnrxo_IGvSUCBBAN_-29HJnzX_MU
and here is the media PUT from Firefox (ie. the one that breaks the file association)
firefox
PUT /upload/drive/v2/files/0B6B-RNrxsCu2UFZxbjExd0dGeTQ?uploadType=media&convert=false&useContentAsIndexableText=true&key=AIzaSyCt2bxTnrxo_IGvSUCBBAN_-29HJnzX_MU HTTP/1.1
Host: content.googleapis.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: text/html; charset=UTF-8
Authorization: Bearer ya29.AHES6ZQrG_PQOmEZD4cBwgrjiNKNZUBc2RzAnOTmZwTJReX664MWvu8
X-ClientDetails: appVersion=5.0%20(X11)&platform=Linux%20x86_64&userAgent=Mozilla%2F5.0%20(X11%3B%20Linux%20x86_64%3B%20rv%3A21.0)%20Gecko%2F20100101%20Firefox%2F21.0
X-JavaScript-User-Agent: google-api-javascript-client/1.1.0-beta
X-Origin: http://foo.myapp.appspot.com
X-Referer: http://foo.myapp.appspot.com
X-Goog-Encode-Response-If-Executable: base64
Referer: https://content.googleapis.com/static/proxy.html?jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.en.l49lMhuyXyk.O%2Fm%3D__features__%2Fam%3DEQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAItRSTOvD2NxxPLz0HiGHMXTek7IhOVTHg
Content-Length: 12
Connection: keep-alive
convert false
key AIzaSyCt2bxTnrxo_IGvSUCBBAN_-29HJnzX_MU
uploadType media
useContentAsIndexableText true
The responses are below. The only difference between the return Item json is that the Chrome version has a mimetype "text/html" whereas Firefox has mimetype "text/html; charset=UTF-8"
firefox response
Content-Length 2986
Content-Type application/json
Date Sat, 24 Aug 2013 10:44:37 GMT
Etag "NaUPR8AuDOKgpQqXUqmAHnRC-Nk/R_dzQ2tl2e997lu1SqOGTX63YoE"
Server HTTP Upload Server Built on Aug 7 2013 16:51:13 (1375919473)
X-Firefox-Spdy 3
"kind":"drive#file",
"id":"0B6B-RNrxsCu2cjlldTNoV01JVHc",
"etag":"\"NaUPR8AuDOKgpQqXUqmAHnRC-Nk/NM5C-3sulAfFZA1V-IIsA-E9_AA\"",
"selfLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc",
"webContentLink":"https://docs.google.com/uc?id=0B6B-RNrxsCu2cjlldTNoV01JVHc&export=download",
"alternateLink":"https://docs.google.com/file/d/0B6B-RNrxsCu2cjlldTNoV01JVHc/edit?usp=drivesdk",
"iconLink":"https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png",
"thumbnailLink":"https://lh3.googleusercontent.com/1KctCx9tjxe6vSn7piLUzfYQuNKQVzMUd6Phn8dTdlHKfQlQsXi77PyOOLkwS-0q3g=s220",
"title":"burcu",
"mimeType":"text/html; charset=UTF-8",
"labels":{
"starred":false,
"hidden":false,
"trashed":false,
"restricted":false,
"viewed":true
},
"createdDate":"2013-08-24T10:44:12.851Z",
"modifiedDate":"2013-08-24T10:44:36.440Z",
"modifiedByMeDate":"2013-08-24T10:44:36.440Z",
"lastViewedByMeDate":"2013-08-24T10:44:36.440Z",
"parents":[
{
"kind":"drive#parentReference",
"id":"0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"selfLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/parents/0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"parentLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"isRoot":false
},
{
"kind":"drive#parentReference",
"id":"0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"selfLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/parents/0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"parentLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"isRoot":false
}
],
"downloadUrl":"https://doc-0k-54-docs.googleusercontent.com/docs/securesc/i6kcvi4n5dug3hk78lqkpogagkdpecs6/krhjojomqafnrdg6943a1fhtnfjg4b8v/1377338400000/15125351317662028975/15125351317662028975/0B6B-RNrxsCu2cjlldTNoV01JVHc?h=16653014193614665626&e=download&gd=true",
"userPermission":{
"kind":"drive#permission",
"etag":"\"NaUPR8AuDOKgpQqXUqmAHnRC-Nk/ajH3QRzRTY6aEeYY5k2JAipDckI\"",
"id":"me",
"selfLink":"https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/permissions/me",
"role":"owner",
"type":"user"
},
"originalFilename":"burcu",
"fileExtension":"",
"md5Checksum":"47088846bea0768b700fa76afc1e2aee",
"fileSize":"6",
"quotaBytesUsed":"6",
"ownerNames":[
" Demo"
],
"owners":[
{
"kind":"drive#user",
"displayName":" Demo",
"isAuthenticatedUser":true,
"permissionId":"15125351317662028975"
}
],
"lastModifyingUserName":" Demo",
"lastModifyingUser":{
"kind":"drive#user",
"displayName":" Demo",
"isAuthenticatedUser":true,
"permissionId":"15125351317662028975"
},
"editable":true,
"copyable":true,
"writersCanShare":true,
"shared":false,
"appDataContents":false,
"headRevisionId":"0B6B-RNrxsCu2MWN5clphQUlBNStwM1FLTWZWS3R0RkViVkh3PQ"
}
chrome response
content-length:
2977
content-type:
application/json
date:
Sat, 24 Aug 2013 10:48:29 GMT
etag:
"NaUPR8AuDOKgpQqXUqmAHnRC-Nk/pESqU9sAUSQgLet1Hkz2wJT0Nyw"
server:
HTTP Upload Server Built on Aug 7 2013 16:51:13 (1375919473)
status:
200 OK
version:
HTTP/1.1
{
"kind": "drive#file",
"id": "0B6B-RNrxsCu2cjlldTNoV01JVHc",
"etag": "\"NaUPR8AuDOKgpQqXUqmAHnRC-Nk/7kdHmkAGWmpQ_v_pNZFbF-GLMic\"",
"selfLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc",
"webContentLink": "https://docs.google.com/uc?id=0B6B-RNrxsCu2cjlldTNoV01JVHc&export=download",
"alternateLink": "https://docs.google.com/file/d/0B6B-RNrxsCu2cjlldTNoV01JVHc/edit?usp=drivesdk",
"iconLink": "https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png",
"thumbnailLink": "https://lh4.googleusercontent.com/AXTF6nVY78BZi00eTaAEwmdTfeXVC5Ny3zYEIVEPOTwPNGqy7LC9dKiqzZBg9-q3LA=s220",
"title": "burcu",
"mimeType": "text/html",
"labels": {
"starred": false,
"hidden": false,
"trashed": false,
"restricted": false,
"viewed": true
},
"createdDate": "2013-08-24T10:44:12.851Z",
"modifiedDate": "2013-08-24T10:48:27.913Z",
"modifiedByMeDate": "2013-08-24T10:48:27.913Z",
"lastViewedByMeDate": "2013-08-24T10:48:27.913Z",
"parents": [
{
"kind": "drive#parentReference",
"id": "0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"selfLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/parents/0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"parentLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2RVVQZ1NFWGZYUW8",
"isRoot": false
},
{
"kind": "drive#parentReference",
"id": "0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"selfLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/parents/0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"parentLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2MFZ0dEx6a2xEQU0",
"isRoot": false
}
],
"downloadUrl": "https://doc-0k-54-docs.googleusercontent.com/docs/securesc/i6kcvi4n5dug3hk78lqkpogagkdpecs6/krhjojomqafnrdg6943a1fhtnfjg4b8v/1377338400000/15125351317662028975/15125351317662028975/0B6B-RNrxsCu2cjlldTNoV01JVHc?h=16653014193614665626&e=download&gd=true",
"userPermission": {
"kind": "drive#permission",
"etag": "\"NaUPR8AuDOKgpQqXUqmAHnRC-Nk/ajH3QRzRTY6aEeYY5k2JAipDckI\"",
"id": "me",
"selfLink": "https://content.googleapis.com/drive/v2/files/0B6B-RNrxsCu2cjlldTNoV01JVHc/permissions/me",
"role": "owner",
"type": "user"
},
"originalFilename": "burcu",
"fileExtension": "",
"md5Checksum": "423f5e2804f551616956ca8cb4a684b0",
"fileSize": "9527",
"quotaBytesUsed": "9527",
"ownerNames": [
" Demo"
],
"owners": [
{
"kind": "drive#user",
"displayName": " Demo",
"isAuthenticatedUser": true,
"permissionId": "15125351317662028975"
}
],
"lastModifyingUserName": " Demo",
"lastModifyingUser": {
"kind": "drive#user",
"displayName": " Demo",
"isAuthenticatedUser": true,
"permissionId": "15125351317662028975"
},
"editable": true,
"copyable": true,
"writersCanShare": true,
"shared": false,
"appDataContents": false,
"headRevisionId": "0B6B-RNrxsCu2Zmg1M0todDBPcERUREtmTjZuQjlCQjJIOUVJPQ"
}
I'll answer my own question by saying this is a bug.
To summarise, using the GAPI Javascript client with Firefox to update content is causing the mime-type in Drive to include the character set (eg. "text/html; charset=UTF-8"). Because this doesn't match the mime-type declared in the API Console ("text/html"), the Drive webapp doesn't associate the file with my application.
The bug could be deemed to be in one of three places:-
It could be a GAPI JS client bug that it is setting the content-type header to be "text/html; charset=UTF-8".
It could be a Drive SDK bug, that the file mime type should always be the one I explicitly declared when I created the file, and should ignore the mime type header of any media uploads. Or it could be considered that the Drive SDK should strip the character set from the content-type header before using it to set the mime type on the file.
It could be a Drive webapp bug, that it should consider "text/html" and "text/html; charset=UTF-8" to be the same mime type.
Related
DEVICE_GROUP_NOT_FOUND in iotagent-ul
I'm trying to send measurements using IoT Agent UL2.0. First, I created a device as follows: POST /iot/devices HTTP/1.1 Host: localhost:4061 Fiware-Service: Empresa1 Fiware-ServicePath: /empresa1 Content-Type: application/json Cache-Control: no-cache { "devices": [ { "device_id": "A6", "entity_name": "A6", "entity_type": "E6", "attributes": [ { "object_id": "a", "name": "aaa", "type": "text" }, { "object_id": "b", "name": "bbb", "type": "text" }, { "object_id": "c", "name": "ccc", "type": "text" } ] } ] } Then I'm trying to send measurements as follows: POST /iot/d?i=A6&k=A6&d=a|7|b|7|c|7 HTTP/1.1 Host: localhost:7896 Fiware-Service: Empresa1 Fiware-ServicePath: /empresa1 Content-Type: text/plain Cache-Control: no-cache But I'm getting the following error: { "name": "DEVICE_GROUP_NOT_FOUND", "message": "Couldn\t find device group" } What the device group is? Thanks!
I figured out how to solve it. I just changed config.defaultTransport to HTTP in config.js and used TEF as apikey. The request that effectively sent measures to Orion was the following: POST /iot/d?i=A6&k=TEF&d=a|7|b|7|c|7 HTTP/1.1 Host: localhost:7896 Fiware-Service: Empresa1 Fiware-ServicePath: /empresa1 Content-Type: text/plain Cache-Control: no-cache I hope this helps somebody.
be careful, you need to configure a service, so that you can use your own API KEY, and that can be done by issuing an HTTP request like this POST http://130.206.80.40:5371/iot/services Headers: { 'Content-Type': 'application/json', 'X-Auth-Token' : '[TOKEN]', 'Fiware-Service': 'openiot', 'Fiware-ServicePath': '/' } Payload: { "services": [ { "apikey": "4jggokgpepnvsb2uv4s40d59ov", "cbroker": "http://0.0.0.0:1026", "entity_type": "thing", "resource": "/iot/d" } ] }
The previous answer from jose-manuel-cantera is correct. Also, pay attention in the resource field should start with a slash /. I was having the same issue as yours, see this ticket https://github.com/telefonicaid/iotagent-ul/issues/459.
Raw body payload in AWS API Gateway Body Mapping Template
For some reason I'm having a hard time getting the raw body from within the event. It's logging the $input.body as json for a application/json content-type. The docs say that that should contain the raw payload. Here my Integration Request Body Mapping Template: { "body" : $input.json('$'), "rawBody": $input.body, "headers": { #foreach($header in $input.params().header.keySet()) "$header": "$util.escapeJavaScript($input.params().header.get($header))" #if($foreach.hasNext),#end #end }, "method": "$context.httpMethod", "params": { #foreach($param in $input.params().path.keySet()) "$param": "$util.escapeJavaScript($input.params().path.get($param))" #if($foreach.hasNext),#end #end }, "query": { #foreach($queryParam in $input.params().querystring.keySet()) "$queryParam": "$util.escapeJavaScript($input.params().querystring.get($queryParam))" #if($foreach.hasNext),#end #end } } Here's the payload example: { "event": { "body": { "hello": "meow" }, "rawBody": { "hello": "meow" }, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US", "Cache-Control": "no-cache", "CloudFront-Forwarded-Proto": "https", "CloudFront-Is-Desktop-Viewer": "true", "CloudFront-Is-Mobile-Viewer": "false", "CloudFront-Is-SmartTV-Viewer": "false", "CloudFront-Is-Tablet-Viewer": "false", "CloudFront-Viewer-Country": "US", "Content-Type": "application/json", "Host": "7nuy7lymef.execute-api.us-east-1.amazonaws.com", "Origin": "file://", "Postman-Token": "0ce7c6f4-3864-c9b4-f2db-739737b2ba49", "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Postman/4.2.2 Chrome/47.0.2526.73 Electron/0.36.2 Safari/537.36", "Via": "1.1 1eea0bca59557555878da4d9775c509f.cloudfront.net (CloudFront)", "X-Amz-Cf-Id": "SDjaGcuJ5eVkOMMCn6M3vGaVicA1fuA7h0bUYE4ARlKupO60eeYNFA==", "X-Forwarded-For": "206.71.230.14, 205.251.250.135", "X-Forwarded-Port": "443", "X-Forwarded-Proto": "https", "x_example_header": "my awesome header" }, "method": "POST", "params": {}, "query": { "example_param": "myawesomeparam" } }, "context": { "callbackWaitsForEmptyEventLoop": false, "logGroupName": "/aws/lambda/reggi-log-post", "logStreamName": "2016/06/08/[$LATEST]aad04e0e46614c288ac8ca43d0a95076", "functionName": "reggi-log-post", "memoryLimitInMB": "128", "functionVersion": "$LATEST", "invokeid": "6e4e1e13-2dc1-11e6-a1f7-4dad3a8eb122", "awsRequestId": "6e4e1e13-2dc1-11e6-a1f7-4dad3a8eb122", "invokedFunctionArn": "arn:aws:lambda:us-east-1:562508364089:function:reggi-log-post" } } Is there any way to access the raw body from this request? Is there any way to change the content-type to accept all types?
The following blog post explains in detail how to get around this problem. https://nicholasjackson.io/2016/12/13/using-graphql-with-aws-lambda/ It's written specifically in the context of GraphQL, but it will work for any content type. In short: Go to the Binary Support section. Enable binary support for your chosen media type and save. Return to the your method in Resources section and open Integration Request. Add/edit the body mapping template for your chosen content type and put the following: "rawBody": "$util.escapeJavaScript($util.base64Decode($input.body))" Save and redeploy the API. Adding binary support encodes the request as a base64 string. The body mapping template decodes it.
$input.body contains the raw payload. You need to put quotes around it like "rawBody": "$input.body". Otherwise the body will be interpreted as part of the json document.
Adding product via google shopping json API 400 must specify product
I'm having trouble getting a product insertion request working with google shopping API (https://developers.google.com/shopping-content/v2/reference/v2/products/insert). I'm sending an authenticated post request to https://www.googleapis.com/content/v2/shop_id/products?dryRun=true but only getting status: 400 with error message: { "error": { "errors": [ { "domain": "global", "reason": "required", "message": "[product] INSERT request must specify product" } ], "code": 400, "message": "[product] INSERT request must specify product" } } My request looks like this (shortened for brevity and ssl encrypted) POST /content/v2/<removed>/products?dryRun=true HTTP/1.1 Host: www.googleapis.com Content-Length: 2102 accept-encoding: gzip, deflate authorization: Bearer <removed> user-agent: Python-httplib2/0.9.1 (gzip) { "offerId": 4572, "gtin": "4048669296057", "googleProductCategory": "Apparel & Accessories > Clothing", "targetCountry": "se", "title": "Puma Sweat Pants", "onlineOnly": true, "price": { "currency": "SEK", "value": "1337" }, "channel": "online", "contentLanguage": "sv", "brand": "Puma", "link": "http://example.com/produkt/puma-sweat-pants" } I know the request is correctly authenticated as I can remove the authentication and get a different message. Googles Common errors page (https://developers.google.com/shopping-content/v2/how-tos/common-errors) suggests that this is a batch job, but that would be the url https://www.googleapis.com/content/v2/products/batch
I found the reason for my troubles: I was not sending the Content-Type: application/json header.
Getting a Server-Side JsonParseException / Char code 31 on Index Creation via Nest
Good afternoon, I am currently struggling a bit with index creation requests towards a hosted Elastic Search Service (FacetFlow), more precisely, the ES server returns a JsonParseException and returns a http 500 response and the Nest client (correctly) reports the index creation request to have failed (non valid/not acknowledged etc) I sniffed the http traffic via fiddler and what gets sent over is the following: POST https://myhostedesinstance.west-eu.azr.facetflow.io/users-dev HTTP/1.1 Accept: application/json Content-Type: application/json Accept-Encoding: gzip,deflate Authorization: Basic <cutforobviousreasons> Host: myhostedesinstance.west-eu.azr.facetflow.io Content-Length: 891 { "settings": { "index": { "number_of_replicas": 0, "number_of_shards": 1 } }, "mappings": { "user": { "_all": { "enabled": false }, "_ttl": { "enabled": false }, "properties": { "dateOfBirth": { "index": "not_analyzed", "type": "date" }, "gender": { "index": "not_analyzed", "type": "integer" }, "username": { "index": "not_analyzed", "type": "string" }, "usernameSuggestions": { "type": "completion", "payloads": false }, "id": { "index": "not_analyzed", "type": "string" }, "createdAtUtc": { "index": "not_analyzed", "type": "date" } } } } } ..and what I get back is the following: HTTP/1.1 500 Server Error Server: nginx/1.4.7 Date: Wed, 01 Jul 2015 21:17:11 GMT Content-Type: application/json; charset=UTF-8 Content-Length: 199 Connection: keep-alive Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true {"error":"JsonParseException[Illegal character ((CTRL-CHAR, code 31)): only regular white space (\\r, \\n, \\t) is allowed between tokens\n at [Source: [B#a4fb74c; line: 1, column: 2]]","status":500} I am using Nest 1.6.1 and Json.Net 7.0.1 and to 'me' that Json sent over to the server looks fine.. or am I missing something? Does anyone happen to know what might be going on? I have not changed any serialization settings of Nest/Json.Net so I am somewhat confused why this might happen.
Docusign rest api composite template error
I've made composite templates and had them working before, but I'm suddenly getting an error and have no idea why this is causing an issue. Here's my request: POST https://demo.docusign.net/restapi/v2/accounts/356019/envelopes HTTP/1.1 Host: demo.docusign.net X-DocuSign-Authentication: <DocuSignCredentials><Username>test#gmail.com</Username><Password>*****</Password><IntegratorKey>****</IntegratorKey></DocuSignCredentials> Content-Type: multipart/form-data; boundary=MY_BOUNDARY Accept: application/json Content-Length: 807319 Expect: 100-continue Connection: Keep-Alive --MY_BOUNDARY Content-Type: application/json Content-Disposition: form-data { "emailSubject": "Please Docusign this", "emailBlurb": "This is a test... Also sign this form", "enableWetSign": "true", "status": "sent", "compositeTemplates": [ { "inlineTemplates": [ { "sequence": "1", "recipients": { "signers": [ { "email": "test#gmail.com", "name": "test", "recipientId": "1" } ] } }], "document": { "documentId": "1", "name": "test0", "fileExtension": "pdf" } } ] } --MY_BOUNDARY Content-Type: application/pdf Content-Disposition: file; filename="test0.pdf"; documentid="1" <pdf bytes here> --MY_BOUNDARY-- I have this working with server templates, but it seems like anything that requires the document object gives me a bad request. The request I'm getting is: Request Error: BadRequestDocuSign Error: { "errorCode": "UNSPECIFIED_ERROR", "message": "the document is corrupt, rebuilding failed" } I've read the pdf bytes in another program and have successfully created a pdf from it, so I'm not sure what could be causing this issue. Does anybody know what the problem may be? Thank you for your time.