* Document the "you tried to use plain HTTP" response from Reverse
Proxy in the appropriate section.
* Switch URL for Gateway.py to `live` branch.
* 'disallowed' Schema Validation error cites **value**, not key *name*.
* Call out the possible need to explicitly subscribe to the empty topic
in order to receive messages... and that currently server-side topic
filtering isn't possible.
* Expand the initial blurb into a full 'About' section.
* Making 'Using EDDN' an actual section, to facilitate migrating away
from the wiki page.
* Guide players towards some useful information (guide and sites).
* Ensure developers know to check the *live* documentation.
* Explicitly link to the current wiki page and EDDN status.
* Add 'Hosting of the live service' section, and only list the current
situation (Vivio hosting is 4-5 years ago now, and Anthor's was never
called out).
The whole build/install process is dependent on the EDDN_ENV value
anyway, so we might as well use it.
This way if a future setup doesn't have a specific string in CWD this
check doesn't break.
Yes, this whole check means you MUST be building from a git checkout,
not the files sourced by some other means.
These are what I was using on my home server to test the prior code
changes to how the Gateway code reports errors.
Ultimately these should become a part of proper tests, but for now
they're at least in the repository for anyone to utilise.
* This code worked if the request was *properly* form-encoded, with a
'data' key whose value was a valid message.
* It failed to detect where the request was form-encoded, with without a
'data' key. It would just assume 'not form-encoded' in that case, then
fail later on JSON parsing.
Thus, re-use the `urlparse.parse_qs()` check for form-encoded format.
This passes:
1. Properly, `data` key, form-encoded with valid value is fully JSON
parsed, schema checked and accepted.
2. *NOT* compressed *or* form-encoded valid message is properly parsed
and accepted.
2. Uncompressed, form-encoded, but no `data` key correctly returns the
same error status and body as the compressed+form-encoded+no data key
path.
* Make lots of 'obvious' things explicit, e.g. HTTP 1.1, not HTTP/2, and
HTTPS not plain HTTP.
* The live service should always be using the schemas as present in the
live branch, not master or another branch.
* A 'good' message will receive 'HTTP 200' status *and* a body of `OK`.
This looks at gateway.log files for any 'ERROR' lines. The output
should be any lines representing an error that hasn't yet been reported
to the softwareName's developer.
NB: Absolutely relies on the developer changing the softwareVersion
after applying a fix.
* This code worked if the request was *properly* form-encoded, with a
'data' key whose value was a valid message.
* It failed to detect where the request was form-encoded, with without a
'data' key. It would just assume 'not form-encoded' in that case, then
fail later on JSON parsing.
Thus, re-use the `urlparse.parse_qs()` check for form-encoded format.
This passes:
1. Properly, `data` key, form-encoded with valid value is fully JSON
parsed, schema checked and accepted.
2. *NOT* compressed *or* form-encoded valid message is properly parsed
and accepted.
2. Uncompressed, form-encoded, but no `data` key correctly returns the
same error status and body as the compressed+form-encoded+no data key
path.
For some reason the milliseconds portion of the %S timestamp is using a
comma for decimals separator, despite 'locale' saying we're set to (US)
English. /tableflip
Actually some logging was already there, just the logger had never been
set up properly, but then I decided to make the format of this message
more useful.
