Rule criteria doesn't work with custom header

[makandre]

SUMMARY

The doc states:

If the criteria key contains any special characters (like -) then use the dictionary lookup format for specifying the criteria key. In case of a webhook based rule it is typical for the header of the posted event to contain such values:

criteria:
trigger.headers['X-Custom-Header']:
type: "eq"
pattern : "customvalue"

So I was trying a rule to receive a simple GitHub issues webhook, with the criteria defined like so:

But the rule is not run.

I know I have defined the webhook correctly, because if I changed the criteria to something else, like trigger.body.action eq opened, it works.

STACKSTORM VERSION

Paste the output of st2 --version:
st2 3.3dev (201c05882), on Python 3.6.9

OS, environment, install method

Post what OS you are running this on, along with any other relevant information/

• e.g. Docker, Vagrant, Kubernetes, etc. Describe how you installed ST2
• e.g. one-line install, custom install, etc -->

Installed on Kubernetes cluster using Helm

Steps to reproduce the problem

Show how to reproduce the problem, using a minimal test-case. Make sure to include any content
(pack content - workflows, actions, etc.) which are needed to reproduce the problem.

• I have GitHub pack installed
• create a rule:
  • webhook trigger w/ url = github
  • criteria (as above)
  • action set to github.add_comment

Expected Results

What did you expect to happen when running the steps above?

Rule runs the action upon receiving an issues webhook from GitHub

Actual Results

What happened? What output did you get?

Nothing runs

Making sure to follow these steps will guarantee the quickest resolution possible.

Thanks!

[amanda11]

I have managed to get this to work on a StackStorm 3.3 system with python 2. Example rule

---
  name: "test_webhook"
  enabled: true
  pack: amanda
  description: "Test hook"

  trigger:
    type: "core.st2.webhook"
    parameters:
       url: sampleamanda

  criteria:
    trigger.headers['X-Parse-Application-Id']:
      type: 'eq'
      pattern: 'hello'

  action:
    ref: core.echo
    parameters:
      message: 'Found header'

Tested with curl:
curl -H "St2-Api-Key: " -k -H 'content-type: application/json' -H "X-Parse-Application-Id: hello" -d '{"arg1":"HELLOAMANDA"}' https://127.0.0.1/api/v1/webhooks/sampleamanda

[amanda11]

I just installed the pack on a standalone CentOS 8.1 python3 and installing the rule from the pack then all was fine.

[amanda11]

To clarify the rules were created from YAML rather than in UI and on StackStorm 3.2 not 3.3 dev.

I did struggle initially when trying to enter via UI, so not sure if any problems when inputting via the UI. (But once I had it imported and cut/pasted into previous rule then it worked).

There is also a UT that tests headers with hyphens in: ./st2reactor/tests/unit/test_enforce.py.

It might be worth trying to create the rule via YAML to confirm if it can be created correctly that way if that's possible.

[makandre]

Sorry but I'm new to stackstorm, so I'm not really sure how to create a rule aside from doing it via the UI.

[amanda11]

I think I might have found the problem.
Could you define the rule as X-Github-Event-Id and see if that works. (i.e. Github not GitHub).

I managed to reproduce the problem with the rule and curl sending in X-GitHub-Event-Id. But if I changed the rule to match X-Github-Event-Id then it worked. It is possible that could be a curl problem, but I think that it might be something along the path or code that translates the header id to X-Github-Event-Id

[makandre]

Nice, it works. Thank you.

Just for the record on GitHub it shows the header is X-GitHub-Event

[arm4b]

@amanda11 Based on your research and discussion in Slack, turns out the original issue is that StackStorm treats headers in a case-sensitive way, while according to RFC http headers are case-insensitive and so X-Github-Event vs x-github-event or X-github-event are the same headers.

Can you please open a dedicated issue/bug report so we don't forget about it?
If you're interested in fixing it, - that would be nice too!

Also, it's a great find!

[arm4b]

@makandre I assume this could be closed as resolved. Feel free to re-open, if needed.

Additionally @amanda11 created a separated issue in #4998 about treating http headers as case-insensitive items, according to RFC.