@uppy/aws-s3: Could not read the ETag header - still experiencing this issue with B2 in @uppy/aws-s3: 4.2.3

[ericvanular]

Initial checklist

• [x] I understand this is a bug report and questions should be posted in the Community Forum
• [x] I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

.use(AwsS3, {
    getUploadParameters: async (file) => {
      // Generate pre-signed url from B2
      const response = await fetch('/api/upload/get_signed_url', {
        method: 'post',
        headers: {
          accept: 'application/json',
          'content-type': 'application/json'
        },
        body: JSON.stringify({
          file_name: file.name,
          contentType: file.type
        })
      })
      const data = await response.json()
      return {
        method: data.method,
        url: data.url,
        headers: {
          'Content-Type': file.type,
          'X-Bz-File-Name': data.file_name,
        },
      }
    },

Steps to reproduce

I have seen a number of closed issues relating to this error, such as #5565, #5516, #1762 which are all supposedly fixed in recent versions

However I am still experiencing the @uppy/aws-s3: Could not read the ETag header error when uploading to Backblaze B2 (S3-like service) in the most recent version @uppy/aws-s3: 4.2.3

I have verified that my CORS settings are configured correctly as requested.

Expected behavior

I expect the upload to return metadata to my front end and allow subsequent processes

Actual behavior

File uploads are succeeding but the error blocks my front end from the next steps in the software process

[ericvanular]

Furthermore, I can see that the Etag header was successfully returned from the presigned PUT call upon successful upload

[jantiegges]

Not sure if this helps anyone, but I also encountered this issue. The reason was that Cloudflare was removing ETags returned by my backend because they were not correctly formatted: https://developers.cloudflare.com/cache/reference/etag-headers/#behavior-with-respect-strong-etags-disabled. invalid: 123 valid: "123"

After fixing this by quoting them correctly, Cloudflare would sometimes convert them to weak ETags, which again made them invalid.

So always make sure the ETag is correctly formatted and not lost in the process.

[franciscohermida]

Not sure if this helps anyone, but I also encountered this issue. The reason was that Cloudflare was removing ETags returned by my backend because they were not correctly formatted: https://developers.cloudflare.com/cache/reference/etag-headers/#behavior-with-respect-strong-etags-disabled. invalid: 123 valid: "123"

After fixing this by quoting them correctly, Cloudflare would sometimes convert them to weak ETags, which again made them invalid.

So always make sure the ETag is correctly formatted and not lost in the process.

@jantiegges it helped me, not sure if I would ever figure out such an issue, thank you, after 5 hours fighting this I can sleep!

[samialdury]

For anyone encountering this issue - It looks like the headers in CORS policies are case-sensitive. This is how I solved it when using Cloudflare R2:

[
  {
    "AllowedOrigins": [
      "http://localhost:5173" // replace with your origin
    ],
    "AllowedMethods": [
      "GET",
      "PUT",
      "POST"
    ],
    "AllowedHeaders": [
      "Authorization",
      "x-amz-date",
      "x-amz-content-sha256",
      "content-type"
    ],
    "ExposeHeaders": [
      "ETag", // <--- IMPORTANT
      "Etag", // <--- IMPORTANT
      "Location"
    ],
    "MaxAgeSeconds": 3000
  },
  {
    "AllowedOrigins": [
      "http://localhost:5173" // replace with your origin
    ],
    "AllowedMethods": [
      "GET"
    ],
    "MaxAgeSeconds": 3000
  }
]