Follow

Okay, this is weird...

I have a server written in that can accept HTTP PUT requests on a particular URI:

github.com/virtadpt/exocortex-

I also have a client written in Python which sends messages to the server on that URI with PUT requests:

github.com/virtadpt/exocortex-

Here's what's messing with me:

On my x86-64 boxen, this works just fine. It does what you'd expect, reliably, on demand. On my Raspbian machines, though, the exact same request doesn't work. The JSON doesn't deserialize.

Has anyone ever seen this before?

More weird: If I try to interact with it using cURL, it works on my x86-64 boxen, but not my RasPi.

curl -X PUT --header "Content-type: application/json" -d '{"name": "BigBoss", "reply": "This is a test."}' http://localhost:8003/replies

Show thread

I think I've figured it out.

I patched the following into my XMPP bridge:

arguments = json.loads(content.decode())

in this method:

github.com/virtadpt/exocortex-

And it worked. Now making the change, pushing, and doing a test deploy.

Show thread

Pushed to Github. Deployed to armhf, and it worked.

Deployed to x86-64, and yeah, seems like it's working.

It might have to do with the fact that Raspbian (or the version I have on my RasPi units) is v3.5, while my x86-64 boxen have v3.7.2 (Arch) and v3.6.7 (Ubuntu).

`ansible exocortex -a "systemctl --user restart xmpp_bridge.service"`

💥

Show thread

@drwho Well, there'll be a lot of excess stuff in the trace, but ultimately it has to open a socket to the destination, doesn't it? ... I mean, doesn't it? ??

@yojimbo It does, yeah. And I can see it send stuff (I'm running both client and server with `--loglevel debug`).

has a built-in tracer, I just learned. I ran Systembot like this:

`python -mtrace --trace ./system_bot.py | egrep '^system_bot.py'`

Nothing there. Let's try the server, now:

python -mtrace --trace ./exocortex_xmpp_bridge.py | egrep '^rest.py'

And I get this:

rest.py(186): response = self._deserialize_content(content)
rest.py(245): arguments = {}
rest.py(247): try:
rest.py(248): arguments = json.loads(content)
rest.py(249): except:
rest.py(250): logging.debug('400, {"result": null, "error": "You need to send valid JSON. That was not valid.", "id": 400}')
rest.py(251): self._send_http_response(400, '{"result": null, "error": "You need to send valid JSON. That was not valid.", "id": 400}')
rest.py(210): self.send_response(code)
rest.py(211): self.send_header("Content-Type", "application/json")
rest.py(212): self.end_headers()
rest.py(213): self.wfile.write(json.dumps(response).encode())
rest.py(214): return

Not really helpful. Hmm.

@drwho ... OK, then ... you're talking HTTP, not HTTPS ... so wireshark and see what's being actually sent?

@yojimbo Not a bad idea. Hang on... that looks about right.

@drwho goodness your exocortex repo looks intense, you've got a lot of stuff in here :blobwoah:

@chuck I've got some oddly specific tools in there. Where possible I try to hook into things that have fairly reasonable APIs.

Kodi, incidentally, does not have anything resembling a reasonable API.

@drwho i'm all too familiar with that. its what drove me to plex

@drwho is it the .decode("ascii") or the .loads() that's failing? Does it fail the same way if you do it in the repl?
Btw json is utf8 not ascii but that shouldn't affect what you're seeing here ...

@eqe It's the .loads() that's failing. If I do it in the REPL (mocking up as best I can with copy-and-paste), it works.

...

I just tried it again. It works as expected.

The .decode() is just for debugging output.

@eqe I suspect something changed in between 3.x releases, but I don't yet know what. I'll see if I can figure it out tomorrow from the changelogs.

I definitely have a few more things to learn insofar as text is concerned.

@drwho when debugging things like this I like to print with "%r", which sometimes provides a clue what's wrong with the object in question. You can often cut n paste the output into the repl.

@eqe %r... I'm going to read up on this. Thank you!

@drwho sorry for the late reply, but I ran into this with diff archs. Try a decode before parsing json. It's typically only on 3.7 backward incompatible issues but might just be implementation specific.

@wamp3ter That's what I wound up doing - it seems like the pattern here is, .decode() anything coming from outside, .encode() everything before it leaves the program.

3.7 has broken an impressive amount of stuff by claiming async as a keyword. It's frustrating.

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.