forward client's 'accept-encoding' header when proxying to upstream?

[elos4]

I'm using OLS as a reverse proxy. Currently, even if a client sends a 'accept-encoding: br' header with the request, openlitespeed changes it to 'gzip' when forwarding the request to the upstream.

But the problem is that the upstream server responds with a gzipped version, and lightspeed forwards the same gzipped file instead of unzipping it and rezipping it with brotli, as long as the client also supports gzip.

My question is -- is it possible for me to change the 'accept-encoding: gzip' header that litespeed sends to the upstream and make it 'accept-encoding: gzip,br' so that the whole chain can be upgraded to brotli whenever the client supports it?

Or even better, can I just have Litespeed forward the 'accept-encoding' header received from the client? I couldn't see any way to configure which headers are forwarded and which ones are not.

 

[David]

Can you tell me which version you are using?

 

[elos4]

I'm on the 1.6.x series, the latest from your downloads page.

I did some more tests. I understood this to be the situation:

If the downstream request contain accept-encoding gzip, then the request is fulfilled by giving gzip. If it doesn't contain gzip, but contains deflate, then the uncompressed version is given, even if br is also an option requested.

The only thing I have to check for now is what happens if I enable caching at the reverse-proxy level. Will it convert the gzip fetched from the upstream into brotli, store it and serve it the next time someone gives an option of br, or will it continue to serve only gzipped versions?

I can, of course, manually place br zipped versions of the pages in the cache, in which case it might send the br version, as it doesn't have to encode it on the fly. But it's very difficult to monitor and manage the freshness of these br versions and to keep updating them as they become stale.

Moreover, I'm having some trouble getting the cache set up. I should be able to figure that out soon though.

PS: This should be enough to get the cache working, right? I don't have php on the reverse-proxy. So, no plugins can be used:

# 1
checkPrivateCache 0
checkPublicCache 1
maxCacheObjSize 10000000
maxStaleAge 200
qsCache 1
reqCookieCache 1
respCookieCache 1
ignoreReqCacheCtrl 1
ignoreRespCacheCtrl 0

enableCache 1
expireInSeconds 6000
enablePrivateCache 0
privateExpireInSeconds 3600

This is the error produced:

2019-12-06 15:43:06.566791 [ERROR] [137.97.86.255:53908:HTTP2-1#news] [Module:Cache] createEntry failed.

I'm not sure whether it's permission issue, as I don't know the location of lscache folder. I've not been able to locate the same yet. I'm not using any panels or anything where I can set the lscache location.

 

[elos4]

Oops, it was my mistake. I was looking under 'Web Server' field, while there was a specific box for Header Ops in the 'Proxy' context. I was under the impression that both were identical.

 

[elos4]

I also found out that 1.6 deletes some of the required config variables related to br. I had to manually restore it.

also, giving 777 permissions on the cache folder was the only way to allow permission to the lsws to write to it. 666 was not enough.