Header merge works as append

[Simbiat]

I am not sure if it's a bug or I am doing something incorrectly, but it looks like when I try to use "merge" for custom headers (through "Context" feature), instead of merging the headers, it appends the new values.
Simplest example, which does work in Apache: I want to ensure that "Vary" header always have "Origin,Save-Data,Accept-Encoding", which by default is not the case. By default, images have only "Accept-Encoding" at best (usually they do not have anything) and regular pages have "Save-Data,Accept-Encoding". I could use "set", but I have some dynamic pages, that may have their own "Vary", which I want to preserve and thus only add the missing values.
With Apache, I've just used "Header merge vary Origin,Save-Data,Accept-Encoding" and it worked perfectly, providing

Yes, sometimes, it changed the order, but that's not a problem. The point is, that the "Origin" value, that was missing from default was added.
With OLS, though, I get this:

which looks an awful lot like result of "append", rather than merge, which is definitely not expected.

So, is this a bug? Or am I missing some setting somewhere that prevents proper merger?
If someone knows of a possible workaround for this, that would be good for me, too.

 

[Cold-Egg]

I will forward the req to the team.

 

[Simbiat]

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

 

[Simbiat]

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 append command should trigger, but... It triggers still. In fact, if I use some other header (initially empty) header like this:

Header append x-test-header test "expr=%{req_novary:x-test-header} !~ m#(^|,)\s*test\s*(,|$)#/i"
Header append x-test-header test "expr=%{req_novary:x-test-header} !~ m#(^|,)\s*test\s*(,|$)#/i"

I will get 2 "test" entries in the final value.
My gut feeling tells me, that "merge" uses similar (if not even same) expression internally and, perhaps, it's not working, because wrong variable is being compared.

 

[Simbiat]

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

 

[LiteCache]

Header append does the same and is the preferred method to add headers with the same name, at least with LSWS.

 

[Simbiat]

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.

 

[LiteCache]

Append may result in duplicate entries in a header.

No, it doesn't, at least not with me and if I append headers in .htaccess and with LSWS.

 

[LiteCache]

that is the way it works in Apache

Forget Apache. With LSWS|OLS the rules of the game are a bit different.

 

[Simbiat]

No, it doesn't, at least not with me and if I append headers in .htaccess and with LSWS.

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 Origin

does not result in a duplicate value - that's another unexpected behavior.

Forget Apache. With LSWS|OLS the rules of the game are a bit different.

LSWS/OLS documentation refers you to mod_apache documentation for directives, that LiteSpeed supports. So, one would logically expect them to behave the same way, as in Apache. If they do not behave the same way and that is expected by the devs - documentation needs to be updated accordingly.

 

[LiteCache]

Do you also believe in Santa Claus or the promises of advertising?

 

[LiteCache]

That doesn't necessarily mean that LiteSpeed is doing something different or wrong. It has turned out in recent years that Apache has not adhered to the RFC.

 

[Simbiat]

Do you also believe in Santa Claus or the promises of advertising?

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, so that support engineers (like me during work hours) would not waste time on investigating something for the clients, that does not even need investigating.

 

[LiteCache]

I, as a developer, believe, that if a developer says that something works a certain way

That's an honor, but things are a little different in sales and marketing.

 

[Simbiat]

That's an honor, but things are a little different in sales and marketing.

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?

 

[LiteCache]

I'm the wrong person to direct your criticism to. I've been working with LSWS for more than 10 years and have learned my lessons that the rules of the game are just a little different with LSWS|OLS. Accept these rules of the game or wear yourself out by them. In the end you can't change anything about it.

 

[LiteCache]

FYI: LiteSpeed is a small company with only a few employees who are constantly changing. You can hope for a lot, but expect very little. Especially no big changes. Much of what LiteSpeed does is good and follows a coherent philosophy, but the low staffing makes it difficult to change that philosophy.

 

[Simbiat]

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 be a problem and why it may be a good idea to adjust this or maybe even implement a new feature. My only expectation from here is that my feedback is listened to, and I get a proper response, that is either "You are right, we will do this", or "We can't do this right now, but we've added it to our backlog", or "No, we can't/won't do this because...", where "because" is something actually justifiable, understandable and not "just because we don't want to".
I believe, these is a natural expectation, especially, when I am already a paying customer.

 

[LiteCache]

Again, adapt to the situation or wear yourself out. You have every right to complain, but in the end you have to adapt to the situation.

 

[Simbiat]

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