Closed vkorenev closed 9 years ago
I guess you're using this non-conforming JSON because some exchange uses that? There are some OpenRTB fields that were poorly specified and later changed/clarified, but I don't remember that Site.cat or Publisher.cat were among those.
Anyway, I never worried to support uncompliant JSON and I'd expect a case like this to result in some error; but an infinite loop is not an acceptable failure mode. Let me try improve this.
I see you've got this sample JSON from a SpotXchange sample, I wonder if it's an obsolete or incorrect sample? Even if not, worst-case it's easy to modify the JSON serializer to handle the cat
fields as scalar (I guess with CSV internally to allow multiple elements).
Doing that without a fork is not very clean, e.g. you can extend OpenRtbJsonReader
and override readSite()
, but then you have to copy that entire method to only change the parsing code for one field. Same for the writer. I could refactor these methods in two pieces, allowing to override only a readSiteFields()
method where you'd only handle one field and super-call for others. Will consider this as a future improvement.
Alternatively, I could make the serializer "smarter", allowing a single value without []
in lieu of an array, but this is only trivial to implement for arrays of scalar values. If the array may contain objects, it's more complicated. On top of that I don't think it's a good idea to support what is effectively an uncompliant extension of OpenRTB... unless this kind of extension turns out to be common so people need to customize the serializer for multiple exchanges.
Fixed in commit 380f29b7fec31391d725fa2aaa463372e62e5eb8
The following JSON causes the bid request parser to enter infinite loop.
It does not fully conform to OpenRTB 2.2/2.3 specification: site/cat and site/publisher/cat attributes must be arrays of strings, not strings. It was taken from here: https://github.com/openrtb/examples/blob/master/brandscreen/example-request-pc-multi.json