Search results

I am adapting: I am using the workaround support found for now. For my needs it's good enough, although a micro-optimizer deep in my head is saying, that it is not as efficient

I am not expecting my "wants" to be implemented right away or even at all. But I've made a policy for myself, that when I see that something may not be working correctly, or at least it does not match my expectations based on documentation and common logic, - I report it, I justify why this may...

How is marketing related to documentation? And what is the point of this argument, when this has already been reported through ticket and is expected to be relayed to developers for further investigation?

I, as a developer, believe, that if a developer says that something works a certain way - it does. And if it does not - he fixes it, so that it does, or if the change does not fit in the current paradigm of the product - justify, why it's not being fixed. Or, at least, updates the documentation...

Erhm... "Append" by design means that a value is added and only added, without any checks. "Merge" implies checking for a value in a header, and adding it only if there is no such value already in the header. If appending the same value twice, like Header append vary Origin Header append vary...

Append may result in duplicate entries in a header. I would definitely prefer merge to work as expected, that is the way it works in Apache.

A workaround found by support: merge only 1 directive at a time, that is instead of Header merge vary Origin,Save-Data,Accept-Encoding do Header merge vary Origin Header merge vary Save-Data Header merge vary Accept-Encoding

I already moved to LSWS and was not able to get both charset and compression for SVG. Raised a ticket for that.

Interesting: I've tried using append with condition in LSWS (since it's not supported in OLS) like this: Header append vary Accept-Encoding "expr=%{req_novary:VARY} !~ m#(^|,)\s*Accept-Encoding\s*(,|$)#/i" Since "Accept-Encoding" was already present, the expression would be "false", and no...

In case someone will stumble on this, in LSWS (not OLS, sadly) you can do this: Header set header-name "GET, HEAD, OPTIONS" "expr=%{HTTP:header-name} == ''"

Can confirm the same behavior in LSWS

Can confirm the same behavior in LSWS. In fact, it's a bit worse, because it has 3 "Accept-Encoding" entries:

I have an issue with several MIME types, for which I want to set charset in their respective Content-Type header. One of them is regular "image/svg+xml". It looks like the only way to apply charset to the header is to manually modify mime.properties file so that it will have a line like svg...

that's what I may have to do, yes and turned out that 2GBs is the limit for total RAM on server, not the amount of RAM LSWS can use, so looks like LiteSpeed can get a new customer

That's exactly what I have been trying to do for testing: header set x-test-header true OLS sends it normally, if I use the "Headers" field for a "Context" (besides an issue with "merge", that I've reported already), but it seems to completely ignore the directive in any field related to rewrite...

I even checked if "Header" directive works when setup from "Rewrite" section in VHost settings (to exclude any potential issues related to .htaccess file): it did not work in OLS, but it does work in LSWS. Either this is intended, or there may be a bug in OLS.

Confirmed: exact same .htaccess file, that did not work in OLS worked in LSWS without any changes.

that is fine as well. for now. but still, would want to understand whether that's the solution for headers issue or I am doing something wrong with the current setup in OLS.

That's enough for my needs for now. Or at least it looks to be so far

Can it be that processing it may require some other settings? or maybe disabling something? Offtopic, but if I would consider LSWS starter: how many workers OLS use?