Closed egiberti closed 5 years ago
Thanks for catching this. PHP uses different endpoints than all of the other SDKs, because of HTTP caching considerations, and we failed to notice that we hadn't implemented those endpoints in ld-relay because all of our current PHP-using customers (as far as we knew) were using Redis. This will be added in the next ld-relay
release after 5.6.0.
I just tried a build with version 5.6.1 and it still behaves the same way, returning a 404 when accessing /sdk/flags
. Do you have any idea when a version that will support this will be released?
Sorry, I should have said "the next ld-relay
minor version release" since this would be new behavior (even though it should have been implemented before). The 5.6.1 release was an unrelated bugfix patch, as described in the release notes. I don't know of the exact time frame for implementing this, but will update this issue to keep you posted.
This is implemented in the 5.7.0 release.
Currently some endpoints return an HTTP 404 from the
ld-relay
host. This is problematic if runningld-relay
in relay proxy mode. Switching to daemon mode can alleviate this in some cases, but adds a dependency on Redis to application code. The alternative is adding logic to the application to make some requests through the relay and others directly to the LaunchDarkly service.Example request:
This adds a couple of entries to the logs and comes back with no flags.
Looking in the PHP SDK code to see what URL is being requested shows
/sdk/flags
. Making that request viacurl
directly to theld-relay
host confirms what the logging stated before, a missing endpoint.The same request on the LaunchDarkly app host
app.launchdarkly.com
returns a JSON blob of current flag data; as expected. Ideally, the request would be answered with the state already stored inld-relay
and transparently proxied through to LaunchDarkly in the event the flag state isn't currently in memory.