[Bug] invalid jsonpath when key has "@" in its name

[cedvan]

Expected Behavior

jsonpath should resolve correctly

Actual Behavior

Using the response of a previous request to set an environment variable errors out when the json property has a : in its name

Reproduction Steps

Use this json (response from another request):

{
  "hydra:member": [
    { 
      "@id': "/entities/xxxx",
      ...
    },
    { ... },
    { ... }
  ],
  "hydra:totalItems": 3
}

use $['hydra:member'][0]['@id'] as the jsonpath expression, live preview shows:
Invalid JSONPath query: $['hydra:member'][0]['@id']

Is there an existing issue for this?

• I have searched the issue tracker for this problem.

Additional Information

This solution worked great before and was broken with recent updates

Insomnia Version

2021.6.0-1

What operating system are you using?

Other Linux

Operating System Version

Linux 5.10.70-1-MANJARO #1 SMP PREEMPT Thu Sep 30 15:29:01 UTC 2021 x86_64 GNU/Linux

Installation method

AUR package

Last Known Working Insomnia version

2021.5.3

[dimitropoulos]

Hi! Thanks for reporting. Ultimately the problem here is with JSONPath being a sorta ill-defined spec itself. Check out https://cburgmer.github.io/json-path-comparison/ for a taste of how much variation there is.

I dug into this and there's some good news:

TLDR, use ` to escape the @

$['hydra:member'][0]['`@id']

---

I created https://mockbin.org/bin/cdc1f76d-b720-4a91-abbc-f0410f2f4222/view for the sake of testing this. It returns:

{
  "hydra:member": [
    {
      "@id": "0123-4567-8888",
      "type": "Avenger"
    },
    {
      "@id": "0123-4567-8910"
    }
  ],
  "@test": true
}

It's not anything to do with :, it's actually the @ that's the troublemaker.

This query works just fine:

$['hydra:member'][0]

But when you introduce the @ is when the problem starts. The issue is that @ is a reserved character in jsonpath and different libraries handle it a little differently based on some vagueness in the spec. Recently in a PR we updated to jsonpath-plus because the prior npm, jsonpath, was blocking a major project and (apparently, by the issues on jsonpath repo) no workarounds to the problems we hit existed.

Despite having test coverage for this (in insomnia-plugin-response), this specific case wasn't one of them. The part that's unfortunate is that both jsonpath and jsonpath-plus are "JSONPath Spec Compliant" ™️, and yet, clearly, as you have seen, they have subtly different behaviors in places.

I can confirm this is a regression, but I'm going to raise this to the rest of the team to know more about changes in the future. I doubt we're going to be switching back to jsonpath for one thing because (as far as we know) we can't, but for another that jsonpath-plus has double the weekly downloads (almost a million) and is more regularly maintained, and seems just healthier overall.

Here's an example of it working with the latest release:

Adding to the above, I'd also like to note that, at least (as an upside) the behavior on jsonpath.com seems to more closely map to what jsonpath-plus does than what the jsonpath npm does.

[dimitropoulos]

Separate of this specific syntax issue, I'd like to ask whether jq syntax would have been preferable to you in this case. We're building a case all the time, it seems, for doing that (see #777) and I wanted to know if that would have been just as good a solution to your problem in this instance.

[cedvan]

Great ! Thanks for your reply, the escape solution with ['`@id'] perfectly solve the problem :).

The integration of jq may be top to allow more manipulations.