On Tue, May 20, 2014 at 02:58:56PM -0600, Sasha Pachev wrote:
> >
> > OK I understand better now. However, I think that this transformation
> > is very specific and if we go down that route we'll have many similar
> > ones. I suggest that instead we focus on applying sed-like regex-based
> > transformations which will allow this and many other things at the same
> > time.
>
> I will redo it using regular expressions and rename the option replace-header.
>
> >
> > Also, in your case, you seem to apply the change to the first header
> > found only, though in theory it should be applied to every header value
> > or every header line depending on the use case. That's probably one more
> > reason for doing it a-la-sed :-)
>
> 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
