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

Make netext httpext Response's Request a pointer #2271

Merged
merged 1 commit into from
Dec 13, 2021

Conversation

oleiade
Copy link
Member

@oleiade oleiade commented Nov 30, 2021

A tiny PR making the Request attribute of netext/httpext/Response struct a pointer. This should avoid copies of said Request objects (as they can be rather big) to be made every time we instantiate a Response. This is in line with Go's standard library.

This is a tiny change, which, as far as I can tell, does not break tests. I've also verified that it does not break the JSON serialization of requests (pointers can be tricksters on that front).

ref #1931

Making the Request attribute of the Response struct a pointer
will avoid making copies of said Request objects (as they can
be rather big) everytime we instantiate a Response.

This is in line with the Go standard library.
@oleiade oleiade self-assigned this Nov 30, 2021
@na-- na-- removed their request for review December 2, 2021 14:40
Copy link
Collaborator

@codebien codebien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mostly exists for response.request.body but is it useful? Could be the same think Go is doing an option?

// Request's Body is nil (having already been consumed).

from:

	// Request is the request that was sent to obtain this Response.
	// Request's Body is nil (having already been consumed).
	// This is only populated for Client requests.
	Request *Request

Copy link
Contributor

@yorugac yorugac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ATM, I'm not sure if this change will solve the problems mentioned in #1931 but it seems harmless enough. I have a question though: how does it correlate with the module's PR #2226 ?

@oleiade
Copy link
Member Author

oleiade commented Dec 13, 2021

@yorugac This tiny refactor is the result of both reading about #1931 and discussions I've had with @mstoykov. It doesn't claim in any way to be directly related/fixing #1931. Hence me only refering it to said issue, and not marking it as closing, to indicate it popped out in the same context. My bad if there was any confusion on that front 😸. I'm not sure I see correlation with #2226, or at least not ones that keep from merging this. Do you have anything specific in mind?

@codebien I am not entirely sure I understood your point, could you elaborate? Regardless of the larger context, I only meant to post a tiny improvement here, in the spirit of the broken window theory: not necessarily to make a big structural change. If there are larger implications, I would prefer to open and address them as a separate issue if that's okay with you 😸

PS: Sourcegraph shows the Response's request is actually used in a few places accross the standard library.

Cheers 🐻

@yorugac
Copy link
Contributor

yorugac commented Dec 13, 2021

@oleiade I simply meant if there can be a conflict between this PR and #2226, as they're changing the same code: I didn't really look at the #2226 since I'm not among the reviewers there so wished to clarify that point. Anyway, I suppose @na--'s approval can be interpreted as an indirect answer being "no conflicts" 🙂

@na--
Copy link
Member

na-- commented Dec 13, 2021

Anyway, I suppose @na--'s approval can be interpreted as an indirect answer being "no conflicts" slightly_smiling_face

Rather "I need to rebase anyway, so I can fix any conflicts that arise" 😅

@mstoykov
Copy link
Collaborator

I don't really this helps all that much (and now I understand what you meant "doesn't use a pointer" when we're talking about this). The problem I was talking about with you about "the response having a copy of the request"(I think that is what I said) isn't so much it's a copy it's that it has the whole request with all of its different fields and in particular having the Body of the request as a string.

I do think this is better though so 👍 ;)

p.s. @codebien I think you are conflating http.Request (from the standard library) and httpext.Request (which is discussed here) - the second doesn't even have a copy of the first (which might be an interesting change 🤔 )

@oleiade oleiade merged commit fa8e949 into master Dec 13, 2021
@oleiade oleiade deleted the fix/keep_responses_request_as_ptr branch December 13, 2021 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants