{"action":"created","issue":{"url":"https://api.github.com/repos/elastic/logstash/issues/2381","repository_url":"https://api.github.com/repos/elastic/logstash","labels_url":"https://api.github.com/repos/elastic/logstash/issues/2381/labels{/name}","comments_url":"https://api.github.com/repos/elastic/logstash/issues/2381/comments","events_url":"https://api.github.com/repos/elastic/logstash/issues/2381/events","html_url":"https://github.com/elastic/logstash/issues/2381","id":54920509,"number":2381,"title":"Support for draft-ietf-json-text-sequence","user":{"login":"wsanchez","id":50002,"avatar_url":"https://avatars.githubusercontent.com/u/50002?v=3","gravatar_id":"","url":"https://api.github.com/users/wsanchez","html_url":"https://github.com/wsanchez","followers_url":"https://api.github.com/users/wsanchez/followers","following_url":"https://api.github.com/users/wsanchez/following{/other_user}","gists_url":"https://api.github.com/users/wsanchez/gists{/gist_id}","starred_url":"https://api.github.com/users/wsanchez/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wsanchez/subscriptions","organizations_url":"https://api.github.com/users/wsanchez/orgs","repos_url":"https://api.github.com/users/wsanchez/repos","events_url":"https://api.github.com/users/wsanchez/events{/privacy}","received_events_url":"https://api.github.com/users/wsanchez/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/elastic/logstash/labels/discuss","name":"discuss","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":22,"created_at":"2015-01-20T18:30:09Z","updated_at":"2016-03-16T08:52:40Z","closed_at":null,"body":"logstash should ingest JSON data in this form: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/\r\n\r\nBasically, that means `RS + JSON + LF`.\r\n\r\nSince log stash already handles `JSON + LF`, a trivial parser could simply delete the leading RS character.  A smarter one would use this to detect truncated JSON text and recover the following record, as described in the spec.\r\n"},"comment":{"url":"https://api.github.com/repos/elastic/logstash/issues/comments/197215898","html_url":"https://github.com/elastic/logstash/issues/2381#issuecomment-197215898","issue_url":"https://api.github.com/repos/elastic/logstash/issues/2381","id":197215898,"user":{"login":"glyph","id":716529,"avatar_url":"https://avatars.githubusercontent.com/u/716529?v=3","gravatar_id":"","url":"https://api.github.com/users/glyph","html_url":"https://github.com/glyph","followers_url":"https://api.github.com/users/glyph/followers","following_url":"https://api.github.com/users/glyph/following{/other_user}","gists_url":"https://api.github.com/users/glyph/gists{/gist_id}","starred_url":"https://api.github.com/users/glyph/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/glyph/subscriptions","organizations_url":"https://api.github.com/users/glyph/orgs","repos_url":"https://api.github.com/users/glyph/repos","events_url":"https://api.github.com/users/glyph/events{/privacy}","received_events_url":"https://api.github.com/users/glyph/received_events","type":"User","site_admin":false},"created_at":"2016-03-16T08:52:40Z","updated_at":"2016-03-16T08:52:40Z","body":"> @glyph - Look again, h['x'].size is 1 not 6.\r\n\r\nYes, I understand that.\r\n\r\n> From the JSON spec, \\x1e is not legal in JSON Strings.\r\n\r\nLet's be precise.\r\n\r\nFrom the JSON spec, a JSON *string* may contain the code point U+001E, but in the *input* to a compliant JSON parser, the code point U+001E may not appear; if it occurs in a string being serialized as JSON, it must be escaped via the JSON escaping mechanism, i.e. it must be represented within double quotes as `\\u001e`, e.g. U+005E U+0075 U+0030 U+0030 U+0031 U+0065.\r\n\r\n> The issue here is not what the Ruby interpreter 'sees' in single or double quotes - it is what the JSON parser 'sees' as it tokenizes the character sequence \"\\x1e\" or \"\\u001e\".\r\n\r\nIn my earlier example, I was demonstrating that the code point U+001E is illegal in the context of JSON input (it needs to be escaped).  You suggested that my \"encoding was wrong\", and that I needed to use \\u001e rather than \\x1e.  But, since I was using double-quoted ruby strings, \\x1e was shorthand for U+001E.  I can switch to a \\u escape sequence and there's no difference in the error:\r\n\r\n```ruby\r\nirb(main):001:0> require(\"JSON\")\r\n=> true\r\nirb(main):002:0> JSON.parse \"{\\\"x\\\": \\\"\\u001e\\\"}\"\r\nJSON::ParserError: 784: unexpected token at '{\"x\": \"\"}'\r\n\tfrom /Users/glyph/.rbenv/versions/2.3.0/lib/ruby/2.3.0/json/common.rb:156:in `parse'\r\n\tfrom /Users/glyph/.rbenv/versions/2.3.0/lib/ruby/2.3.0/json/common.rb:156:in `parse'\r\n\tfrom (irb):2\r\n\tfrom /Users/glyph/.rbenv/versions/2.3.0/bin/irb:11:in `<main>'\r\nirb(main):003:0> \r\n```\r\n\r\nSo I am providing neither the character sequence \"\\\\\" \"x\" \"1\" \"e\" nor the character sequence \"\\\\\" \"u\" \"0\" \"0\" \"1\" \"e\" in either of these cases; in both, I am providing just the code point \"\\u001e\".\r\n\r\nThe point here is that we do not worry about U+001E being featured as valid whitespace in input, or relaxing any delimiting rules in the specification to allow it to appear; it will be rejected by all commonly-used parsers and by the spec."}}