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

net/http/httptrace: Provide direction in the documentation for ClientTrace on safety of request mutations #39153

Open
thesilentg opened this issue May 20, 2020 · 6 comments
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@thesilentg
Copy link

thesilentg commented May 20, 2020

The documentation for ClientTrace provides no guidance on if it is safe to modify the request from within any of the trace functions. It mentions that the functions within ClientTrace may be called concurrently, but does not comment on if these functions are permitted to modify the request. In contrast, the documentation for RoundTripper explicitly calls out the expected behavior:

    // RoundTrip should not modify the request, except for
    // consuming and closing the Request's Body. RoundTrip may
    // read fields of the request in a separate goroutine. Callers
    // should not mutate or reuse the request until the Response's
    // Body has been closed.

This concern was originally raised when attempting to use GotConn to modify the request Header to add the amount of time remaining until the request's context deadline, for use in distributed tracing. I would like to be able to modify certain properties in the request (Headers, Body, ...) in response to ClientTrace data, but need to understand if that behavior will continue to be supported.

This issue has two components:

  1. Provide guidance on if the functions within ClientTrace are permitted to modify the request
  2. If the functions within ClientTrace are permitted to modify the request, promise this expectation will continue in the future by updating the documentation to reflect this
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 21, 2020
@cagedmantis cagedmantis added this to the Backlog milestone May 21, 2020
@cagedmantis
Copy link
Contributor

/cc @bradfitz @bcmills

@thesilentg
Copy link
Author

@cagedmantis Hi Carlos, just wanted to check in and see if there was anyone else you think would be able to help answer this. It's been about a month at this point, and even just getting general directional guidance with regards to mutability would be helpful. Thanks!

@thesilentg
Copy link
Author

thesilentg commented Apr 12, 2021

@cagedmantis @bcmills Just wanted to check in and see if there was anyone else you think would be able to help answer this. It's been about a year at this point, and even just getting general directional guidance with regards to mutability would be helpful. Thanks!

@thesilentg
Copy link
Author

@cagedmantis @bcmills Do you think it will be possible to get an answer on this?

@thesilentg
Copy link
Author

@cagedmantis @bcmills Will it be possible to get an answer here?

@bcmills
Copy link
Member

bcmills commented Sep 26, 2023

(attn @neild)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants