[milutinke]

Good job

[Dreizehnt]

Hi, I have a problem:

L 08/14/2017 - 19:07:16: [RIPEXT] HTTP request failed: Error reading ca cert file /etc/ssl/certs/ca-certificates.crt - mbedTLS: (-0x3E00) PK - Read/write of file failed

Technical support for hosting where I rent the game server states that the extension visits the directories above the server folder and should not do this. How to be? And what actions are performed in the folder: /etc/ssl/certs/

[klippy]

It's because SSL_CERT_FILE environment variable is set to that path (which your user doesn't have permission to read). I guess you are trying to access a HTTPS endpoint? However, I don't know a fix. I'm sure you could Google that errors because it's a cURL error, it doesn't come from the extension.

[DJ Tsunami]

Version 1.0.3 now comes with the CA bundle in the configs/ripext folder, instead of it being hardcoded to /etc/ssl/certs/ca-certificates.crt. This fixes the issue above and also allows you to replace it with your own CA bundle if your API isn't trusted.

[rio_]

Is there no way to see if a key exists in a JSONObject? Even GetString produces an exception if the key doesn't exist, and only returns false if the key is set but is null. I feel like that's a huge piece that's missing... It shouldn't be up to the API you're communicating with to insert a null value for every possible key it could return.

[asherkin]

Hmm, that behaviour is wrong according to the SourceMod error model - errors should always be avoidable and thus always caused by programmer error (either due to misuse or missing checks).

[DJ Tsunami]

Originally Posted by rio_ It shoudn't be up to the API you're communicating with to insert a null value for every possible key it could return.

I agree, it shouldn't. You should know which fields are returned based on the API's documentation. And APIs should be versioned so that changes don't break existing calls.

Originally Posted by asherkin errors should always be avoidable and thus always caused by programmer error (either due to misuse or missing checks).

I'm not sure what's considered "programmer error" in this case. If you pass an invalid index to an ADT array it throws an error, but if you pass an invalid key to an ADT trie it returns false. So the former is programmer error, but the latter is not?

[splewis]

Originally Posted by DJ Tsunami I'm not sure what's considered "programmer error" in this case. If you pass an invalid index to an ADT array it throws an error, but if you pass an invalid key to an ADT trie it returns false. So the former is programmer error, but the latter is not?

Given an arbitrary adt array it's possible to prevent going out of bounds with a Length check.

Given an arbitrary adt trie it's not possible to prevent a lookup to a non-existing key based on any check - thus the lookups need to be safe.

Even without that the lack of a "key existence check", most languages don't let you index to random parts of dynamic arrays (exception / undefined behavior), but most will let you attempt lookups to non-existent keys in maps.

[asherkin]

Originally Posted by splewis Given an arbitrary adt array it's possible to prevent going out of bounds with a Length check. Given an arbitrary adt trie it's not possible to prevent a lookup to a non-existing key based on any check - thus the lookups need to be safe.

This is exactly it.

(Yes, a KeyExists function and throwing on invalid keys would also be suitable for the error model, but you pay the hash and lookup penalty twice, so it is simpler in that case to do in one go.)

[KyleS]

https://sm.alliedmods.net/api/index....d=show&id=692&

The ADT_Array API doesn't support this behaviour either (see how with GetTrieValue the return is the state of the key, and the param is actually optional (well; should be)).

Anyways; yeah, in a bunch of plugins I do similar things with checking keys; this is definitely the more intuitive approach then erroring out if a single json key is missing (is this really the point of contention???).