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.

Sign up for GitHub

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

Jump to bottom

HttpContext/IHttpContextAccessor article #34592

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open

HttpContext/IHttpContextAccessor article #34592

wants to merge 11 commits into from

Conversation

guardrex
Copy link
Collaborator

@guardrex guardrex commented Jan 29, 2025 •
edited by github-actions bot
Loading

Fixes #34587
Fixes #14974

NoTeS

  • Includes trying to close the issue you, Javier, opened for the SignalR doc set.

  • Not sure on the placement of the SignalR article. Did you prefer just a section? Where do you want the article in the ToC, or where do you want the section if I take that content and make it into a section? IMO, Blazor should have this guidance surfaced better than a section. Pop open the whole Blazor article on the DIFF to review the entire Blazor article. This gets rid of the INCLUDE that I was using before that was burying this content ... devs aren't always finding it as a section.

    UPDATE: Yes! This is the direction that we should go in.

  • I'd like to keep the "advanced" cross-links. Dev are asking for more details, and the convos in those issues explain quite a bit, especially the discussion that you, Mackinnion, Steve, and I had on this subject. I hope we can keep it with the lingo that I placed, explaining that it's for "advanced" scenarios and that most devs won't need to look at it. However, I'm ready to 🔪 those cross-links if you want ... I'm just concerned that even more issues will come in if we do.

Internal previews

📄 File 🔗 Preview link
aspnetcore/blazor/components/httpcontext.md aspnetcore/blazor/components/httpcontext
aspnetcore/blazor/components/index.md aspnetcore/blazor/components/index
aspnetcore/blazor/fundamentals/signalr.md aspnetcore/blazor/fundamentals/signalr
aspnetcore/blazor/security/index.md aspnetcore/blazor/security/index
aspnetcore/blazor/security/interactive-server-side-rendering.md aspnetcore/blazor/security/interactive-server-side-rendering
aspnetcore/fundamentals/http-context.md aspnetcore/fundamentals/http-context
aspnetcore/signalr/httpcontext.md aspnetcore/signalr/httpcontext
aspnetcore/toc.yml aspnetcore/toc

@guardrex guardrex self-assigned this Jan 29, 2025
@guardrex guardrex requested a review from javiercn January 31, 2025 12:48
danroth27
danroth27 approved these changes Feb 6, 2025
View reviewed changes
Copy link
Member

@danroth27 danroth27 left a comment

Choose a reason for hiding this comment

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

Looks good to me for Blazor. We should get signoff from the SignalR folks as well.

@danroth27 danroth27 requested a review from mikekistler February 6, 2025 14:51
@guardrex
Copy link
Collaborator Author

guardrex commented Feb 6, 2025

@BrennanConroy for a final look, too. I added a paragraph to address your feedback.

BrennanConroy
BrennanConroy approved these changes Feb 6, 2025
View reviewed changes
Copy link
Member

@BrennanConroy BrennanConroy left a comment

Choose a reason for hiding this comment

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

Wording might want some more massaging, but don't want to block on tiny nits, this is a good improvement.

@guardrex
Copy link
Collaborator Author

guardrex commented Feb 6, 2025

Wording might want some more massaging

I'd prefer to work on it further then. These get left for years 😄. Best to make it as good as possible. I'll try again.

@guardrex
Copy link
Collaborator Author

guardrex commented Feb 6, 2025 •
edited
Loading

Hummmm 🤔 ... I took another look. It sounds good to me. What specifically don't you like? The line is a bit long, so I could break it into two points of a list.

When in the hub, <xref:Microsoft.AspNetCore.SignalR.GetHttpContextExtensions.GetHttpContext%2A?displayProperty=nameWithType> returns either:

* A subset of <xref:Microsoft.AspNetCore.Http.HttpContext> properties from the mocked/faked/shim SignalR HTTP layer for the connection.
* null if the connection isn't associated with an HTTP request.

Call <xref:Microsoft.AspNetCore.SignalR.GetHttpContextExtensions.GetHttpContext%2A> to get HTTP connection information, such as HTTP headers and query strings. For more information, see <xref:signalr/hubs#the-context-object>.

@BrennanConroy
Copy link
Member

When working within a SignalR hub, you can access the HttpContext directly using the xref:Microsoft.AspNetCore.SignalR.GetHttpContextExtensions.GetHttpContext%2A?displayProperty=nameWithType method. This method returns the xref:Microsoft.AspNetCore.Http.HttpContext for the current connection, or null if the connection isn't associated with an HTTP request. This is particularly useful for retrieving HTTP connection information, such as headers and query strings, directly within the hub. It is recommended to use this method over IHttpContextAccessor for accessing HttpContext in the hub. For more details, refer to the SignalR Hubs documentation.

Maybe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@danroth27 danroth27 danroth27 approved these changes

@javiercn javiercn javiercn approved these changes

@BrennanConroy BrennanConroy BrennanConroy approved these changes

@mikekistler mikekistler Awaiting requested review from mikekistler

Assignees

@guardrex guardrex

Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@guardrex @BrennanConroy @danroth27 @javiercn