Actix-web is simply returning "br, gzip, deflate, zstd". No error, no traces

[ganeshrvel]

I have written a server program using actix-web: 4.0.0-beta.15. The program works just fine when accessed via Postman, a web browser or curl.

The same code does not work on an esp8266 IOT module, it simply return this string as the response with the status code as 406

br, gzip, deflate, zstd

I figured that the actix-web Compress middleware was causing this issue.

     HttpServer::new(|| {
        App::new()
            .wrap(middleware::Compress::default())
            .service(index)
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await

I tried adding traces to the actix-web program but there isn't much error/info available there as well.

This is all that I see:

[mio::poll][TRACE] registering event source with poller: token=Token(134217729), interests=READABLE | WRITABLE
[mio::poll][TRACE] deregistering event source from poller

What can be done here to fix this issue?
Is there a way to conditionally disable the Compress middleware after reading a header value?

Arduino code snippet:

    HTTPClient https;
    String fullUrl = "https://127.0.0.1:8000";
    Serial.println("Requesting " + fullUrl);
     if (https.begin(client, fullUrl)) {
         https.addHeader("Accept-Encoding", "gzip, deflate, br");

         https.addHeader("Content-Type", "application/json");
      
         https.addHeader("Accept", "*/*");

         int httpCode = https.GET();

         Serial.println("Response code: " + String(httpCode));
         if (httpCode > 0) {
             Serial.println(https.getString());
         }
         https.end();
      }

[asonix]

This probably isn't the issue, but Content-Type describes the format of the request body, and since you're sending a GET request there is no request body, therefore the Content-Type header is not proper.

In relation to this question: What features have you enabled for actix-web?

[asonix]

I'm confused because you seem to be hitting this case: https://github.com/actix/actix-web/blob/master/src/middleware/compress.rs#L145

But the only way that can happen is if try_parse errors, which can only happen here: https://github.com/actix/actix-web/blob/master/src/middleware/compress.rs#L297

Is it possible that your http client is manipulating your Accept-Encoding header?

[ganeshrvel]

Yes, you were right! The ESP HTTP client was internally manipulating the accept-encoding for the http1.1 requests. The library was adding an extra accept-encoding: "identity;q=1,chunked;q=0.1,*;q=0 to the header. I had to switch to http1.0 to get the compression working