Afaik, all errors except allocation failures do return the error in json form (i had to jump through some hoops to get that working way back then, due to fossil's fail-fast-via-exit() approach to error handling). The mis-triggered alloc report here is, as you say, likely a side effect of the null fields, and should be easy to fix.
Note that you don't need http to feed data to the json layer. There is a cli option (i think it's -json-input, but i am in bed so can't verify that right now) which tells it to read the POST data from a file. ----- stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Jun 7, 2017 04:05, "Warren Young" <war...@etr-usa.com> wrote: > On Jun 6, 2017, at 5:58 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > > > If you leave quotes off of the property names, it's not json > > Yes, but that’s only one of the three problems here. The other two are: > > 1. It should diagnose the error correctly. (The error has nothing to do > with memory allocation.) > > 2. It should return the error message via JSON to the client, not print it > on the console. The JSON API is most likely to be used in cases where the > called Fossil instance is running in the background, with stdio detached. > > > Why that shows up as a response allocation error, i can't say off hand. > > From what debugging I did, it’s because the parsing failure caused most of > the fields of g.json to be unset, which causes multiple levels of NULL to > be returned, which the scream-and-die code misinterprets as given. > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
