[exporters/otlptracehttp] Do not log errors for 2XX response

[songy23]

Fixes https://github.com/open-telemetry/opentelemetry-go/issues/3706

We should accept all 2xx codes, as per HTTP specification. see https://github.com/open-telemetry/opentelemetry-specification/blob/v1.16.0/specification/protocol/otlp.md#json-protobuf-encoding . See what we do in OTLP exporter in collector https://github.com/open-telemetry/opentelemetry-collector/blob/892d07dffbb8dc639114bc0c340dfd4fc5293258/exporter/otlphttpexporter/otlp.go#L146-L149

[songy23]

cc @dineshg13

[codecov[bot]]

Codecov Report

Merging #3707 (c45623a) into main (f5a1497) will not change coverage. The diff coverage is 100.0%.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #3707   +/-   ##
=====================================
  Coverage   79.7%   79.7%           
=====================================
  Files        171     171           
  Lines      12673   12673           
=====================================
  Hits       10103   10103           
  Misses      2357    2357           
  Partials     213     213           

Impacted Files	Coverage Δ
exporters/otlp/otlptrace/otlptracehttp/client.go	77.5% <100.0%> (ø)
sdk/trace/batch_span_processor.go	81.1% <0.0%> (-0.9%)	:arrow_down:
exporters/jaeger/jaeger.go	91.1% <0.0%> (+0.8%)	:arrow_up:

[dineshg13]

Hoisting this as it was on a comment chain that got resolved:

On success, the server MUST respond with HTTP 200 OK.

If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server MUST respond with HTTP 200 OK.

Nothing other than a 200 OK response is according to spec.

The spec says All other HTTP responses that are not explicitly listed in this document should be treated according to HTTP specification. . Any 2xx should be treated as non-error . https://umbraco.com/knowledge-base/http-status-codes/#2xx

cc @Aneurysm9

[songy23]

In other SDKs / components:

• OTLP exporter in collector treats all codes in [200, 300) as success: https://github.com/open-telemetry/opentelemetry-collector/blob/892d07dffbb8dc639114bc0c340dfd4fc5293258/exporter/otlphttpexporter/otlp.go#L146-L149
• 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

public boolean isSuccessful() Returns true if the code is in [200..300), which means the request was successfully received, understood, and accepted.

• Python http exporter treats 200 and 202 as success: https://github.com/open-telemetry/opentelemetry-python/blob/209093bfbe3fae0fc29c693f55d6bb6a2d997aad/exporter/opentelemetry-exporter-otlp-proto-http/src/opentelemetry/exporter/otlp/proto/http/trace_exporter/init.py#L155

Haven't checked others but this seems something needs to be unified.

[Aneurysm9]

The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.

• RFC 9110

The OTel spec for OTLP/HTTP says that servers must respond to fully or partially successful requests with 200 OK. That covers all successful HTTP response scenarios. Any server that responds with 201 Created or 202 Accepted are non-conformant. Encountering a non-conformant server is an error condition.

That other SDKs do something different doesn't mean that we need to follow their lead.

[dineshg13]

@Aneurysm9 @songy23 I have created an issue on Spec . https://github.com/open-telemetry/opentelemetry-specification/issues/3203 . It looks like we need a clarification on the spec for this issue.