You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 1, 2017. It is now read-only.
Copy file name to clipboardExpand all lines: content/changes/2014-04-22-gist-api-now-truncating-large-files.md
+12-14Lines changed: 12 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,23 +10,21 @@ In order to provide the most robust, fast and accurate API for Gist we recently
10
10
###Truncating file contents > 1MB
11
11
Sometimes we need to put some large data into a gist. However, we don't always need to see the full content of that large gist when we're fetching the metadata for gists via the API. This change imposes a sensible (according to our data) limit on the amount of raw file data that is returned in gist fetches via the API. If you're relying on reading the full content of individual files from a gist then you may need to update your flow to perform a followup request for the```raw_url``` resource in order to download the entire contents of the file. Which begs the question:*How do I know if the file's contents have been truncated?*
12
12
13
-
###{ file: {truncated: true, ... } }
13
+
###New files.truncated property
14
14
On the packets that have been truncated you will notice a new key in the files segment of the payload.
In this small example payload, you'll notice the new*truncated* key has been added and the*content* key's value is empty. This would be a case for making a follow up request to the raw_url, if you are looking to get all of the data that would have normally showed up in the content field.