Accept-Encoding is altered on proxy

#1
I have created a simple python script using sockets, I use openlitespeed to proxy to this http backend, I see openlitespeed is altering accept-encoding in requests headers, only if accept-encoding is equal to "br", the accept-encoding is "br", anything else is converted to "gzip", for example if accept-encoding is equal to "br, deflate", the accept-encoding is converted to "gzip", if accept-encoding is equal to "gzip, br" the accept-encoding is converted to "gzip", only if accept-encoding is equal to "br", the accept-encoding is "br".
 
#2
I actually ran into more problems, I found out that openlitespeed always send 'Accept-Encoding: gzip' to the backend, then decompressed the content, then it removes 'Transfer-Encoding: chunked' from the respond headers but never adds a 'Content-Length', which makes sense the openlitespeed converts chinked data to normal data but cannot buffer all chunked data to count the whole respond, but it should not remove the 'Transfer-Encoding: chunked' and leave chunked data as is. It should also respect the 'Accept-Encoding' from the client, even though the user never sends a 'Accept-Encoding', openlitespeed sends a 'Accept-Encoding: gzip' to have a compressed connection with the backend, openlitespeed decompressed the content but the 'Etag' is for the gzipped content.
 
Top