Return more-specific error when input might be application/json-seq #3191
Conversation
JSON Test Sequences, aka JSON-SEQ, aka application/json-seq are defined in https://datatracker.ietf.org/doc/html/rfc7464. Per the RFC, the format is: any number of JSON texts, each encoded in UTF-8 [RFC3629], each preceded by one ASCII RS character, and each followed by a line feed (LF). jq supports this format but requires the --seq parameter to be used in order to correct parse it. If the option is omitted, then an ambiguous and confusing error message is printed. The RFC is designed to avoid this ambiguity: Since RS is an ASCII control character, it may only appear in JSON strings in escaped form (see [RFC7159]), and since RS may not appear in JSON texts in any other form, RS unambiguously delimits the start of any element in the sequence. RS is sufficient to unambiguously delimit all top-level JSON value types other than numbers. This change adds ASCII RS character (0x1e) detection when --seq is omitted, and prints a useful error message recommending to retry with the option. Fixes jqlang#3156.
| @@ -514,6 +514,8 @@ static pfunc check_literal(struct jv_parser* p) { | |||
| case 'f': pattern = "false"; plen = 5; v = jv_false(); break; | |||
| case '\'': | |||
| return "Invalid string literal; expected \", but got '"; | |||
| case 0x1e: | |||
There was a problem hiding this comment.
Use '\036' same as https://github.com/jqlang/jq/blob/master/src/jv_parse.c#L651 ?
There was a problem hiding this comment.
I wonder if the check can/could be in the scan function somewhere after we know p->flags & JV_PARSE_SEQ is not set to keep it closer to the rest of the seq parsing code? or would that affect what input errors it would detect?
I would be good if @nicowilliams (author of the rfc btw!) could have a look
There was a problem hiding this comment.
Oh I didn't even see that sorry, still finding my way around the code base. I'll do some more experimentation.
Ideally, I'd like to just autodetect the RS and switch it to parsing JSON-SEQ but not sure how feasible that is.
There was a problem hiding this comment.
Oh I didn't even see that sorry, still finding my way around the code base. I'll do some more experimentation.
👍 no worries
Ideally, I'd like to just autodetect the
RSand switch it to parsing JSON-SEQ but not sure how feasible that is.
No that familiar with the input code so don't know either. Just error out with nicer error message is good start i think.
JSON Test Sequences, aka JSON-SEQ, aka application/json-seq are defined in
https://datatracker.ietf.org/doc/html/rfc7464. Per the RFC, the format is:
any number of JSON texts, each encoded in UTF-8 [RFC3629],
each preceded by one ASCII RS character, and each followed by a line
feed (LF).
jq supports this format but requires the --seq parameter to be used in order to
correct parse it. If the option is omitted, then an ambiguous and confusing
error message is printed. The RFC is designed to avoid this ambiguity:
Since RS is an ASCII control character, it may only
appear in JSON strings in escaped form (see [RFC7159]), and since RS
may not appear in JSON texts in any other form, RS unambiguously
delimits the start of any element in the sequence. RS is sufficient
to unambiguously delimit all top-level JSON value types other than
numbers.
This change adds ASCII RS character detection when --seq is omitted, and prints
a useful error message recommending to retry with the option.