Help, Parse Error: Content-Length can't be present with Transfer-Encoding

[ShadiestGoat]

I am trying to do a GET request onto 'http://mc.xeno-world.com:25666/v1/graph?server=XenoWorld&type=serverCalendar', but I keep getting the error in title... I know it has smt to do with the headers, but I honestly have no clue how to make it so that it doesnt break apart. I have tried doing the exact same request in the insomnia client, and while it does take it's time, it does respond after about 5 seconds. What Im doing:

    const res = await got(url, {encoding: "utf-8"})

I also get this output along with the usual node traceback:

code: 'HPE_UNEXPECTED_CONTENT_LENGTH',
  timings: {
    start: 1609867194965,
    socket: 1609867194966,
    lookup: 1609867195132,
    connect: 1609867195334,
    secureConnect: undefined,
    upload: 1609867195335,
    response: undefined,
    end: undefined,
    error: 1609867198000,
    abort: undefined,
    phases: {
      wait: 1,
      dns: 166,
      tcp: 202,
      tls: undefined,
      request: 1,
      firstByte: undefined,
      download: undefined,
      total: 3035
    }
  }
}

so if thats helpful :D
Thank you in advance!

[Giotino]

The problems is with the server, its behavior is out of spec.

It sends Transfer-encoding: chunked and Content-length: ####.

Take a look at https://tools.ietf.org/html/rfc2616#section-4.4 for more info.

[ShadiestGoat]

thank you ^^

[snowbldr]

The spec at https://datatracker.ietf.org/doc/html/rfc2616#section-4.4 specifically states that the client should ignore the content-length, not explode...

3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.

[szmarczak]

The RFC above is a bit out of date. See https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2

A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.

It doesn't say anything about ignoring the header.

[snowbldr]

Ah, new RFC, new rules. Thanks for the updated link.