-
Notifications
You must be signed in to change notification settings - Fork 887
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
OTLP HTTP Server Response Code #3203
Comments
Hey @dineshg13! The specification itself is quite clear on this:
opentelemetry-specification/specification/protocol/otlp.md Lines 502 to 504 in 84a5fa3
If your backend follows this spec and only returns |
The requirement for only accepting |
All 2xx codes should be treated as successful, there is a scenario with browsers where the server response MUST return a 204 to avoid browsers from creating excessive connections (which can cause requests to block navigation and never get sent -- resulting in lost telemetry) For clarification, during page unload when the browser is sending requests via the API's used for sending requests (sendBeacon() and fetch() with keep-alive (which are currently the only reliable API's to send requests during page unload)) IF the response returns a 200 this causes browser (chromium specifically) to have to establish a new connection as it ignores the body (because it is not expecting one) and it can't expect that the connection stream is valid, while when a 204 response is returned it can and does reuse the existing connection. To fully "support" this scenario the sender (exporter) should pass a flag to inform the server that if everything is successful and it would have normally returned a 200 (with body) that it should return a 204 and no body. |
We have this in the spec:
So the spec says that the Client must be ready to receive other status codes. The spec does not say when the Server should use these codes. We can try to refine the spec in a way that clarifies what happens when 2xx or 3xx is used. We must make this change in a way that is backward compatible (I am not sure how exactly it can be done). |
I agree with @tigrannajaryan . The spec needs to clarify how the client handles 2xx or 3xx. Considering only 200 as the non-error response seems overly restrictive. |
I think for the 2xx series the spec is fairly conclusive that I think there's a case to be made for allowing For |
@Aneurysm9 Just to clarify
The requirement to return And with (really) old browsers there was no |
Thanks for the clarification @MSNev. I indeed did have my understanding of the landscape backwards. I think the quoted part of my comment can be removed and the rest stands. |
What are you trying to achieve?
We are trying to setup a OTLP HTTP Server, it is not clear if responding with any code other than 200 is considered error. Every SDK is handling this differently.
OTLP exporter n collector treats all codes in [200, 300) as success:
Java otlp http exporter treats all codes in [200, 300) as success: https://github.com/open-telemetry/opentelemetry-java/blob/3d73283a71a2a6e1d6dd5e725098f697b1edae03/exporters/common/src/main/java/io/opentelemetry/exporter/internal/okhttp/OkHttpExporter.java#L120 .
What did you expect to see?
I would expect the specification to say explicitly that any 2xx shouldn't be considered an error.
Additional context.
See discussion on PR open-telemetry/opentelemetry-go#3707
The text was updated successfully, but these errors were encountered: