>> This raises a question. Currently set-header deletes all of the >> earlier versions of the header and replaces them with only one that is >> new. If we are going to be consistent, it would make sense for >> replace-header to behave like set-header in this way. Are you OK with >> set-header and replace-header having a different behavior, do you want >> to change the behavior of set-header, or shall I just leave this part >> as is in my original patch? > > That's an interesting question. The purpose of set-header was to ensure > that there is only one instance of the header on the output, typically > an x-forwarded-for header, so it makes sense to remove all existing ones. > > For replace-header, I'm seeing multiple usages. The term "replace" makes > me think it will remove all instances and put one instead. But then, how > to define what the input is ? > > Maybe we could have two actions with different effects : > - replace-header : iterate over all header *lines* matching the same > name and apply the rule to the whole line. That will work for > set-cookie for example ; This means that '^' and '$' match the > beginning and end of the line. > > - modify-header : iterate over all header *values* of all header > lines, and apply the rule to the value. That will work for all > other ones. This means that '^' and '$' match the beginning and > end of a value, possibly delimited by commas. > > That could also make it easier to manipulate attributes present with > certain headers. > > Do you think that would be OK ? > > Willy >
Sounds like a good idea. To clarify, if we have replace-header Foo-Header (.*) $1bar Input: Foo-Header: a Foo-Header: b Output: Foo-Header: abbar modify-header Foo-Header (.*) $1bar Input: Foo-Header: a Foo-Header: b Output: Foo-Header: abar Foo-Header: bbar ? -- Sasha Pachev Fast Running Blog. http://fastrunningblog.com Run. Blog. Improve. Repeat.
