Contents API used documented Base64 transport for exact file bytes
The file creation endpoint (PUT /repos/{owner}/{repo}/contents/{path}) requires content to be Base64-encoded so its JSON payload can carry arbitrary file bytes. Both models encoded the intended text and succeeded on the first request. The API decodes exactly the supplied bytes: using echo without -n adds a real newline to the source content and therefore creates a file one byte longer; it does not corrupt the encoding. A plain-text convenience input could reduce mechanics for simple files, but no retry, wrong file, or task failure occurred in either run.
How can I reproduce this?
Requires: GitHub PAT with repo contents access and a test repository
- Send plain text in the content field: PUT /repos/{owner}/{repo}/contents/test.txt with { "message": "test", "content": "Hello world" }.
- Encode correctly (echo -n "Hello world" | base64 → SGVsbG8gd29ybGQ=) and resend.
- Encode with a trailing newline (echo without -n → SGVsbG8gd29ybGQK) and resend.
Expected: Plain text returns 422 "content is not valid Base64"; the correct encoding returns 201 with an 11-byte file; the newline variant returns 201 with a 12-byte file because the encoded input contains a newline.
Evidence · transcript moments