[PR #39] [MERGED] Update uploadFileContent for Python client #290

New issue

Closed

opened 2026-03-03 12:10:06 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 12:10:06 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/fsouza/fake-gcs-server/pull/39
Author: @jwhitlock
Created: 6/11/2019
Status: ✅ Merged
Merged: 6/13/2019
Merged by: @fsouza

Base: master ← Head: parse-multipart-range

📝 Commits (2)

e1c425f Update uploadFileContent for Python client
438aec5 Run TestParseContentRange in parallel

📊 Changes

2 files changed (+152 additions, -21 deletions)

View changed files

📝 fakestorage/upload.go (+97 -21)
📝 fakestorage/upload_test.go (+55 -0)

📄 Description

This updates uploadFileContent to handle the needs of both the Go and Python clients when uploading over multiple requests. It rewrites parseRange as parseContentRange, to parse the header content and leave interpretation and setting response headers to uploadFileContent.

The Go client always sends content as one or more chunks without a total size, and, when the stream is exhausted, sends a final request with no content but the final size.

The Go client also sends the header X-Guploader-No-308. This specifies that the response to a "mid-stream" request should be sent with a status code 200 OK plus the header X-Http-Status-Code-Override: 308.

The Python client sends chunks with a total size when known, such as when uploading a file or an in-memory string. Unlike a streaming response, the final request contains content. and the final request contains data. It expects a mid-stream response to have a status code 308 Permanent Redirect.

The Python client is pickier about some response details, and uploadFileContent's responses are changed to work with both the Python and (more flexible) Go clients:

The Python client requires the Range response header to start counting at 0, such as bytes 0-999, while the Go client appears to ignore the start byte.
The Python client requires that the final response is a 200 OK, while the Go client accepts this or a 201 Created.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/fsouza/fake-gcs-server/pull/39 **Author:** [@jwhitlock](https://github.com/jwhitlock) **Created:** 6/11/2019 **Status:** ✅ Merged **Merged:** 6/13/2019 **Merged by:** [@fsouza](https://github.com/fsouza) **Base:** `master` ← **Head:** `parse-multipart-range` --- ### 📝 Commits (2) - [`e1c425f`](https://github.com/fsouza/fake-gcs-server/commit/e1c425f5fd1ba06ead5a66ea197bb65b15d2e368) Update uploadFileContent for Python client - [`438aec5`](https://github.com/fsouza/fake-gcs-server/commit/438aec582de48f87962c7b0713bf701a05bcc1c0) Run TestParseContentRange in parallel ### 📊 Changes **2 files changed** (+152 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `fakestorage/upload.go` (+97 -21) 📝 `fakestorage/upload_test.go` (+55 -0) </details> ### 📄 Description This updates ``uploadFileContent`` to handle the needs of both the Go and Python clients when uploading over multiple requests. It rewrites ``parseRange`` as ``parseContentRange``, to parse the header content and leave interpretation and setting response headers to ``uploadFileContent``. The Go client always sends content as one or more chunks without a total size, and, when the stream is exhausted, sends a final request with no content but the final size. The Go client also sends the header ``X-Guploader-No-308``. This specifies that the response to a "mid-stream" request should be sent with a status code ``200 OK`` plus the header ``X-Http-Status-Code-Override: 308``. The Python client sends chunks with a total size when known, such as when uploading a file or an in-memory string. Unlike a streaming response, the final request contains content. and the final request contains data. It expects a mid-stream response to have a status code ``308 Permanent Redirect``. The Python client is pickier about some response details, and ``uploadFileContent``'s responses are changed to work with both the Python and (more flexible) Go clients: * The Python client requires the ``Range`` response header to start counting at 0, such as ``bytes 0-999``, while the Go client appears to ignore the start byte. * The Python client requires that the final response is a ``200 OK``, while the Go client accepts this or a ``201 Created``. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>