-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add test accessing request.url when transport is closed #3177
Conversation
Interesting problem :) |
This will allow to retrieve information (scheme and remote properties) about the request even after the underlying connection has been closed.
I've looked at the code again and went for the solution that gets the SSL information at connection establishment. I think this approach is better because for example, in my case, some clients close the connection but I still want to log some things (this is why I try to access the request.url property). I'm not sure if this will add a lot of latency for every request, but I'm open to other suggestions. |
Codecov Report
@@ Coverage Diff @@
## master #3177 +/- ##
==========================================
- Coverage 98.11% 98.05% -0.07%
==========================================
Files 43 43
Lines 7846 7853 +7
Branches 1352 1353 +1
==========================================
+ Hits 7698 7700 +2
- Misses 57 60 +3
- Partials 91 93 +2
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, let's do it
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs. |
What do these changes do?
I am finding an issue on production when trying to retrieve the
request.url
property on a closed transport fails. The stacktrace is the following:I found a similar issue already fixed, but it was for the
request.remote
property instead: #2474I'm not really sure what's the best way to fix it, that's why I'm just adding a simple test case to show the problem. Any hint on how to solve it?
This is the test failure:
Are there changes in behavior for the user?
No.
Related issue number
Checklist
CONTRIBUTORS.txt
CHANGES
folder<issue_id>.<type>
for example (588.bugfix)issue_id
change it to the pr id after creating the pr.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.