Return more-specific error when input might be application/json-seq #3191
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
wader
reviewed
Oct 17, 2024
| @@ -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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.