The CL arg won't actually *do* anything yet, because this script doesn't
actually have a logger set up at all. But we need to fake this else
eddn.conf.Settings.loadConfig() won't be called correctly or work.
Fixes the regression identified in #165
However the gzip code path can still erroneously think a decompressed
request body is form encoded when it is not. This happens when any text
in the decompressed body matches the regex:
.+=[^\&;]*
i.e. some text, followed by `=`, and then some more text, possibly
empty, followed by an ampersand `&`, or semi-colon `;`, or the end of the
string.
`&` and `;` are used to separate key=value pairs in form encoding, the
`=` separates a key from its value.
* A few uploading PC softwares are listed to lower the barrier for a new
player finding such. This is *never* going to be an exhaustive list.
* Added section listing console options for contributing data. Again,
not intended to be exhaustive.
* Layout/sections tweaked. Hopefully the use of double horizontal rules
emphasises which section text is a part of.
* 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.
