V2/json empty

[marcstern]

This accepts a valid JSON request with only a number or a string, nothing else.
Example:
--29000000-B--
POST /test/json/test.html HTTP/1.1
content-type: application/json
Host: test
Content-Length: 2
User-Agent: Mozilla 4.0
Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2

--29000000-C--
25
--29000000-F--

I added a test, so I hope it'll be accepted this time.
I had to create the complete (minimal) test for JSON parsing, so I hope it's correct.

[marcstern]

Is it sufficient to have it reviewed?

[zimmerle]

The discussion on how to handle the elements of a JSON into collections - ARGS, in this specific case - was placed for version 3 a while ago. There, it was established a pattern to navigate under the elements giving a flat structure (compatible with collection keys).

The flat structure allows one to select the elements of JSON inside the args; A powerful feature. Within this patch pinpoint, an element does not sound to be feasible. Am I right? Why not adopt the schema presented in ModSecurity version 3?

[marcstern]

I didn't follow the discussion in v3. I can have a look at it if you can point me to it.
Anyway, I imagine that it's a big change. In the meantime (although I'm not sure that you'll invest a lot of time for major changes in v2), it would worth to fix the current situation, no? I don't see any problem with that fix.
If I understood your question, you're wondering if we can access the empty ARG? Indeed: ARGS:/^$/ or ARGS_NAMES "@rx ^$".
So, can we accept this trivial fix?
Thanks

[marcstern]

Any chance to have this merged? Thanks

[marcstern]

Hello guys. Any reason to not review this one-line fix?
I implemented the test, so what's missing?

[martinhsv]

I don't have any concerns with the 1-line fix; I think we can proceed with that.

The only minor caveat I would draw attention to here is that, with this solution, there's no way to tell apart these request bodies (i.e. to ModSecurity they will be considered equivalent):

1

and

{ "" : 1 }

I don't think that's a serious impediment though.

The test, though, I don't think is quite right. For example, it passes even without the 1-line fix to msc_json.c

I'll either fix it up, or omit the test file for now. ( Anyway we probably want to include any such test in the pre-existing file .../rule/15-json.t )

[martinhsv]

This change was committed via substitute pull request #2735