gdrive service can't work under wasm target

[Young-Flash]

let mut cfg: Gdrive = Gdrive::default();
cfg.access_token("...").root("/tmp");

let op = Operator::new(cfg).unwrap().finish();
op.write(
    "test-gdrive-wasm",
    "Hello, WASM! We are from OpenDAL at rust side!"
        .as_bytes()
        .to_vec(),
)
.await
.unwrap();
let bs = op.read("test-gdrive-wasm").await.unwrap();

I am test gdrive over wasm, when I work with the above code, it failed with

but that code works well if I run it in rust side, am I missing something?

originally post at #3808 (comment)

[Zheaoli]

The root cause is here

When the request happens in the browser, the browser will add a default encoding header accept-encoding: gzip which means that the server needs the compressed data. So It would cause an error. The origin data is 243 long and 188 long after compress

cc @Xuanwo

[Zheaoli]

[Young-Flash]

When the request happens in the browser, the browser will add a default encoding header accept-encoding: gzip which means that the server needs the compressed data. So It would cause an error. The origin data is 243 long and 188 long after compress

nice catch

Is this issue just for gdrive service only? (since it isn't report at s3 example)

[Xuanwo]

When the request happens in the browser, the browser will add a default encoding header accept-encoding: gzip which means that the server needs the compressed data. So It would cause an error. The origin data is 243 long and 188 long after compress

Nice catch! We did't hit this since we use no_gzip on non-wasm32 target. But reqwest didn't provide this on wasm32 target.

[Xuanwo]

Hi, @Zheaoli, would you like to try add Accept-Encoding: identity under wasm32?

[Zheaoli]

Hi, @Zheaoli, would you like to try add Accept-Encoding: identity under wasm32?

Unfortunately, It can't be done in the Brower. The Accept-Encoding field is one of the forbidden header fields in the Brower. Which means that we can not change the field value in the JS or the WASM code

FYI :

1. https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
2. https://github.com/chromium/chromium/blob/2898ac290cf80164cee57e7145fe45f858b6ee9f/net/http/http_util.cc#L305-L330

[Zheaoli]

When the request happens in the browser, the browser will add a default encoding header accept-encoding: gzip which means that the server needs the compressed data. So It would cause an error. The origin data is 243 long and 188 long after compress

nice catch

Is this issue just for gdrive service only? (since it isn't report at s3 example)

It will be reported from S3 user in the future. The S3 can open the gzip setting by manually

[Xuanwo]

The Accept-Encoding field is one of the forbidden header fields in the Brower.

Would like to provide more details about that? The example in seanmonstar/reqwest#2073 (comment) seems to work fine.

It does not work - -

[Xuanwo]

A possible way is to implement content-encoding correctly: implement gzip decoding when services return them.

[Zheaoli]

A possible way is to implement content-encoding correctly: implement gzip decoding when services return them.

The most common algorism used by content encoding

1. deflate
2. Brotli
3. Gzip

Maybe we need to support all three algorithm or raise error when the encoding is not supported yet

[Xuanwo]

Maybe we need to support all three algorithm or raise error when the encoding is not supported yet

It's better to handle in the http client (a.k.a reqwest). Let's bring the discussion to upstream instead.