if the request comes in either as a POST or as a PUT it has a body (since all examples report a faily nested query structure, I'd say it's the case vs a simple querystring in a GET)If the body carries the correct content-encoding, it's automatically parsed into request.vars. You can still read the raw body as usual in request.body .
On Thursday, November 17, 2016 at 2:38:57 PM UTC-8, Niphlod wrote:if the request comes in either as a POST or as a PUT it has a body (since all examples report a faily nested query structure, I'd say it's the case vs a simple querystring in a GET)If the body carries the correct content-encoding, it's automatically parsed into request.vars. You can still read the raw body as usual in request.body .Thanks, that helped me to know what to look for. I got the Grafana stuff installed, it does the fake-json-source ok, and with FF developer tools I'm seeing the traffic to my nascent endpoint.When configuring the datasource URL, it does a GET to the base URL (the one just for "checking in", return an HTTP 200; I put a little status json into the response body just for grins). When you configure a panel (the youtube videos they provide are important here) and select a metric , it will do an OPTIONS and then a POST.I had put some CORS headers into my response, because FF is seeing me return data when it accesses the Gravana server. [Sidebar question: does the book cover anything about valid CORS? I didn't find it if it's there; fortunately, there were some good posts in the GG archive. The book does have little bits about providing protection against against black-hat CORS.] The request to me seems to come from the client JS -- since it shows in the network panel -- but FF gives CORS errors if I don't have the headers.So now I just have to make a good response to the metric requests./dps
response from web2py controller? web2py returns bytes. It is up to you to put utf8 or ascii in there. web2y does not care.
On Monday, November 28, 2016 at 3:23:59 PM UTC-8, Massimo Di Pierro wrote:response from web2py controller? web2py returns bytes. It is up to you to put utf8 or ascii in there. web2y does not care.Okay, I overrode the Content-Type header to remove the "charset: utf-8", and I set enforce_ascii in the simplejson.dumps(), but I still have 50 or so single-char objects rather than 1 hierarchical object. I also tried applying str() before the dumps(), without any improvement. Since I'm using FF's network tab, I can't see if there is any difference in the packets, only what FF decoded the packets as.
This is a Ubuntu system (a VM); can I use tcpdump on localhost traffic? I'm using the Rocket server on the web2py side; the fake-source from the Grafana people is using a js server. (I'm not sure if Grafana itself is using a js server, but it does have an internal server to keep track of settings and such.)
On Monday, November 28, 2016 at 11:11:48 PM UTC-8, Dave S wrote:On Monday, November 28, 2016 at 3:23:59 PM UTC-8, Massimo Di Pierro wrote:response from web2py controller? web2py returns bytes. It is up to you to put utf8 or ascii in there. web2y does not care.Okay, I overrode the Content-Type header to remove the "charset: utf-8", and I set enforce_ascii in the simplejson.dumps(), but I still have 50 or so single-char objects rather than 1 hierarchical object. I also tried applying str() before the dumps(), without any improvement. Since I'm using FF's network tab, I can't see if there is any difference in the packets, only what FF decoded the packets as.Any suggestions here?
On Thursday, December 1, 2016 at 12:15:50 AM UTC-8, Dave S wrote:
On Monday, November 28, 2016 at 11:11:48 PM UTC-8, Dave S wrote:On Monday, November 28, 2016 at 3:23:59 PM UTC-8, Massimo Di Pierro wrote:response from web2py controller? web2py returns bytes. It is up to you to put utf8 or ascii in there. web2y does not care.Okay, I overrode the Content-Type header to remove the "charset: utf-8", and I set enforce_ascii in the simplejson.dumps(), but I still have 50 or so single-char objects rather than 1 hierarchical object. I also tried applying str() before the dumps(), without any improvement. Since I'm using FF's network tab, I can't see if there is any difference in the packets, only what FF decoded the packets as.Any suggestions here?Okay, moving my code to a different server lets me do tcpdump, and I see that I am indeed shipping ASCII. What I can also see is that there are quotes (in the tcp packet body) around my json string, both for the hand-crafted json and the responses done with json.dumps() ... is this expected?
On Friday, December 2, 2016 at 12:10:55 PM UTC-8, Dave S wrote:
On Thursday, December 1, 2016 at 12:15:50 AM UTC-8, Dave S wrote:
On Monday, November 28, 2016 at 11:11:48 PM UTC-8, Dave S wrote:On Monday, November 28, 2016 at 3:23:59 PM UTC-8, Massimo Di Pierro wrote:response from web2py controller? web2py returns bytes. It is up to you to put utf8 or ascii in there. web2y does not care.Okay, I overrode the Content-Type header to remove the "charset: utf-8", and I set enforce_ascii in the simplejson.dumps(), but I still have 50 or so single-char objects rather than 1 hierarchical object. I also tried applying str() before the dumps(), without any improvement. Since I'm using FF's network tab, I can't see if there is any difference in the packets, only what FF decoded the packets as.Any suggestions here?Okay, moving my code to a different server lets me do tcpdump, and I see that I am indeed shipping ASCII. What I can also see is that there are quotes (in the tcp packet body) around my json string, both for the hand-crafted json and the responses done with json.dumps() ... is this expected?
I have access to a java-based server that I can get json from, and it doesn't seem to have the whole response wrapped in quotes.