Refactor "Content" for file uploading (#25851)
Before: the concept "Content string" is used everywhere. It has some problems: 1. Sometimes it means "base64 encoded content", sometimes it means "raw binary content" 2. It doesn't work with large files, eg: uploading a 1G LFS file would make Gitea process OOM This PR does the refactoring: use "ContentReader" / "ContentBase64" instead of "Content" This PR is not breaking because the key in API JSON is still "content": `` ContentBase64 string `json:"content"` ``
This commit is contained in:
parent
265a28802a
commit
236c645bf1
15 changed files with 103 additions and 80 deletions
6
templates/swagger/v1_json.tmpl
generated
6
templates/swagger/v1_json.tmpl
generated
|
@ -16125,7 +16125,7 @@
|
|||
"content": {
|
||||
"description": "new or updated file content, must be base64 encoded",
|
||||
"type": "string",
|
||||
"x-go-name": "Content"
|
||||
"x-go-name": "ContentBase64"
|
||||
},
|
||||
"from_path": {
|
||||
"description": "old path of the file to move",
|
||||
|
@ -16810,7 +16810,7 @@
|
|||
"content": {
|
||||
"description": "content must be base64 encoded",
|
||||
"type": "string",
|
||||
"x-go-name": "Content"
|
||||
"x-go-name": "ContentBase64"
|
||||
},
|
||||
"dates": {
|
||||
"$ref": "#/definitions/CommitDateOptions"
|
||||
|
@ -21687,7 +21687,7 @@
|
|||
"content": {
|
||||
"description": "content must be base64 encoded",
|
||||
"type": "string",
|
||||
"x-go-name": "Content"
|
||||
"x-go-name": "ContentBase64"
|
||||
},
|
||||
"dates": {
|
||||
"$ref": "#/definitions/CommitDateOptions"
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue