-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LD GetAllFlags returns 304 - Not modified #142
Comments
Is it for sure that the URL it's hitting has never been requested before by any instance of the JS SDK, in any UIWebView or browser, on this phone? Responses from the LaunchDarkly endpoint for browser flags are cacheable - they have an etag, and the etag will change if any part of the flag configuration has changed. So, if you ran the JavaScript code at some point and it received a response, and then later on some JavaScript code in another WebView made the same request (i.e. same environment and same user properties), it could get a 304 - appropriately - as long as both webview browsers are sharing the same cache. I'm not 100% sure whether UIWebView instances all share the same cache, but based on the responses here, I think it's likely that they are. |
Also, could you clarify whether the JavaScript code is receiving the expected feature flags? |
add debug logging for various things
I'm closing this issue due to inactivity. Let us know if you're still encountering this issue and have responses to Eli's questions. |
Hi,
We have our iOS mobile app launching a webview and inside that webview we are making another connection to LD to get the customers overriding LD feature flags.
In the webview we are expecting this to successfully return with a 200 response, but instead we are seeing a 304 not modified response.
Now the iOS app does establish an event stream which is hitting a different URL, and the web site is only making one single request so we shouldn't be getting a 304 status code in the first place.
Note testing within the browser produces the expected result it is only under the webview are we seeing this odd behaviour.
Thanks.
Jake
The text was updated successfully, but these errors were encountered: