Skip to content
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

validateHTTPStatusCode() does not allow custom status codes #4215

Closed
cleroux opened this issue Jun 9, 2023 · 2 comments
Closed

validateHTTPStatusCode() does not allow custom status codes #4215

cleroux opened this issue Jun 9, 2023 · 2 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists

Comments

@cleroux
Copy link

cleroux commented Jun 9, 2023

Description

Our application supports cancellation of ongoing HTTP requests. When a request is cancelled we return HTTP status 499 which we have defined in our application for this purpose because no other status code seemed appropriate.

We noticed that our tracing spans for cancelled requests are marked as errors and after some investigation I have found that validateHTTPStatusCode() actually checks that the status code is one of the well-known defined status codes. However, my understanding of HTTP status codes is that they are meant to be extensible. Yet there is no way for me to add my custom status code to the validRangesPerCategory map.

From RFC2616:

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human-readable information which will explain the unusual status.

I would first like to understand if strict validation of well-known status codes is actually necessary. I think it would be enough to check that the code is simply within the 1XX to 5XX range.

Environment

  • OS: Ubuntu 20.04
  • Architecture: x86
  • Go Version: 1.20.3
  • opentelemetry-go version: v0.14.0

Steps To Reproduce

  1. Use otelhttp.NewHandler() middleware to instrument an HTTP endpoint
  2. Return a custom HTTP status from the endpoint. Eg. 499
  3. Observe the span has the error attribute set to true

Expected behavior

I expected that the tracing middleware shouldn't care about the specific HTTP status, only the category. And a 4XX, even if it's not a well-known HTTP status, should not set error=true on the span.

@cleroux cleroux added the bug Something isn't working label Jun 9, 2023
@dmathieu
Copy link
Member

Should be fixed by open-telemetry/opentelemetry-go-contrib#3966.

@pellared
Copy link
Member

@pellared pellared closed this as not planned Won't fix, can't repro, duplicate, stale Jun 12, 2023
@pellared pellared added the duplicate This issue or pull request already exists label Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants