Skip to content

Clear Headers After File Upload to Prevent Request Issues #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: dev
Choose a base branch
from

Conversation

darwishdev
Copy link

This PR fixes a bug where headers set during file uploads (such as cache-control, content-type, and x-upsert) persist after the request, causing errors in subsequent API calls. Specifically, after a successful upload with options like upsert: true, the headers remain unchanged, leading to issues when using the storage client for other operations (e.g., listing files).

Reproduction Steps:

  1. Upload a file using the UploadOrUpdateFile function with options like { Upsert: true }:
    	response, err := s.StorageClient.UploadFile('images', 'image.webp', reader,  storage_go.FileOptions{
     	                            ContentType: &req.FileType,
     	                            Upsert:      &isUpsert,
                                 })
  2. Try listing files immediately after the upload:
     response, err := s.StorageClient.ListFiles('images', "", storage_go.FileSearchOptions{
     	                            Limit:  int(req.Limit),
     	                            Offset: int(req.Offest),
                                 })
  3. The following error occurs:
    "body must be object"
    
  4. If we reset the storage_client, the storage client starts working again, indicating that headers were not properly cleared after the upload request.

Fix:

  • Ensured all custom headers are cleared after the request completes using defer, preventing them from affecting future requests.

Issue Resolved:

  • Fixes the "body must be object" error when listing files after an upload with options.

@aboozaid
Copy link

This is a critical issue and this PR needs to be resolved ASAP

@aboozaid
Copy link

As a workaround for now you can use reflect

clientValue := reflect.ValueOf(s.storageClient).Elem()
clientTransportField := clientValue.FieldByName("clientTransport")
headerField := clientTransportField.FieldByName("header")
headerPtr := (*http.Header)(unsafe.Pointer(headerField.UnsafeAddr()))
headerPtr.Del("cache-control")
headerPtr.Del("x-upsert")
headerPtr.Set("content-type", "application/json")

@muratmirgun
Copy link
Member

Hello I check this issue asap!

Thanks for contributions 🎊

@darwishdev
Copy link
Author

darwishdev commented May 29, 2025

@aboozaid you can use my fork
here

on this repo i fixed this issue and added the ability to handle different environments for the supabase client including auth and storage clients

@aboozaid
Copy link

aboozaid commented Jun 7, 2025

@darwishdev I checked your fork but it still has another issue if you have two upload requests at the same time you will get "fatal error: concurrent map writes" error because of both requests try to access the same header at the same time.

Please use sync.Mutex in order to fix that. I return back to my workaround until you solve it :)

clientValue := reflect.ValueOf(s.storageClient).Elem()
clientTransportField := clientValue.FieldByName("clientTransport")
headerField := clientTransportField.FieldByName("header")
headerPtr := (*http.Header)(unsafe.Pointer(headerField.UnsafeAddr()))
mu.Lock()
headerPtr.Del("cache-control")
headerPtr.Del("x-upsert")
headerPtr.Set("content-type", "application/json")
mu.Unlock()

@aboozaid
Copy link

aboozaid commented Jun 7, 2025

It seems like the above solution still does not prevent the issue and it has to be solved from the library itself because I use fileOptions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants