BJbjarteaarmolund·Apr 16, 2026Submission
Critical Breaking Change in Microsoft.AspNetCore.DataProtection
3 points · Open discussiondotnet
aspnetcore
C#2014–2026
dotnet / aspnetcore
aspnetcore
ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
66Distinct people
79Mentions
0Explicit recommenders
38.5KGitHub stars
What to know before exploring
What it is
ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- dotnet/runtime · linked in 5 of the same discussions
- dotnet/core · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year79 dated mentions
Observed mentions: 2014-05-14 08:04:17 UTC to 2026-04-16 12:23:46 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
79 sourcesWriting a fast router can be surprisingly difficult if you are trying to cover the edges. The state of the art is not trivial:
https://github.com/dotnet/aspnetcore/blob/main/src/Http/Rout...
In Build Your Own Router with URLPattern()FYI, the fixed versions were released yesterday, the 14th, in the October 2025 "Patch Tuesday"
at https://dotnet.microsoft.com/en-us/download/dotnet
They are 8.0.21 and 9.0.10
https://github.com/dotnet/core/blob/main/release-notes/8.0/8...
https://github.com/dotnet/core/blob/main/release-notes/9.0/9...
as per https://github.com/dotnet/aspnetcore/issues/64033
In ASP.NET Security Feature Bypass VulnerabilityThis appears to be the code change: https://github.com/dotnet/aspnetcore/commit/97a86434195a82fc...
In ASP.NET Security Feature Bypass VulnerabilityFor context around the score https://github.com/dotnet/aspnetcore/issues/64033#issuecomme...
In ASP.NET Security Feature Bypass Vulnerability.NET Security Feature Bypass Vulnerability
2 points · Open discussionI don't think "was always" is an accurate statement
However, above and beyond free, it is also a collection of ECMA standards https://learn.microsoft.com/en-us/dotnet/fundamentals/standa...
Now, don't get me wrong: I have grave suspicions there is currently only one actual implementation of them (I don't count hobby, or abandonware, ones) but IMHO "actual standard" combined with "for real reference implementation" is way better than just reference implementation
---
since I'm still within the edit window, the MAUI referenced by the sibling comment is MIT licensed https://github.com/dotnet/maui
https://github.com/dotnet/blazor (Apache 2) is marked an archived, and points to https://github.com/dotnet/aspnetcore (MIT) but command-f blazor on its readme is nothing so :shrug:
In Java 25 officially releasedMicrosoft is dogfooding Copilot in their dotnet/runtime [1] and dotnet/aspnetcore [2] repositories. This is the only time I have seen a company using its own AI Tools transparently. Yes, they label it an experiment, but I am pretty sure it’s mandated use within Microsoft.
I am an “AI skeptic”, so clearly I am biased here. What I am seeing in the repositories is, that Copilot hasn’t made any substantial contributions so far. The PRs, that went through? They often contain very, very detailed feedback, up to the point line by line replacements have been suggested.
The same engineers, that went up stage at “Microsoft Build 2025” to tell how amazing Copilot is and how it made them a 100x developer? They are not using Copilot in any of their PRs.
You said it’s a religion. I’d say it’s a cult. Whatever it is, outside the distortion bubble, this
Read the rest
whole thing looks pretty bad to me.
[1] https://github.com/dotnet/runtime/pulls
[2] https://github.com/dotnet/aspnetcore/pulls
Note that Blazor has serious deployment problems since ~2021 [0] due to MS picking some idiotic packaging format defaults.
I.e. Let's make it look like a Windows executable! And go ahead and name it .dll! I'm sure no default firewall settings will have an issue with that.
So any wide Blazor app deployment also requires overriding the default packaging and adding obfuscation.
Supposedly that's experimentally fixed in NET 8... [1]
[0] https://github.com/dotnet/aspnetcore/issues/31048
[1] https://github.com/dotnet/aspnetcore/issues/36978#issuecomme... https://github.com/dotnet/runtime/issues/80807
In Uno Platform Studio: GUI Designer for Cross-Platform .NET Applications> I'm hoping this is satire.
Me too. It's one thing to accept single LFs in protocols that expect CRLF, but sending single LFs is a bridge to far in my opinion. I'm really surprised most of the other replies to your comment currently seem to unironically support not complying with well-established protocol specifications under the misguided notion that it will somehow make things "simpler" or "easier" for developers.
I work on Kestrel which is an HTTP server for ASP.NET Core. Kestrel didn't support LF without a CR in HTTP/1.1 request headers until .NET 7 [1]. Thankfully, I'm unaware of any widely used HTTP client that even supports sending HTTP/1.1 requests without CRLF header endings, but we did eventually get reports of custom clients that used only LFs to terminate headers.
I admit that we should have recognized a single LF as a line t
Read the rest
erminator instead of just CRLF from the beginning like the spec suggests, but people using just LF instead of CRLF in their custom clients certainly did not make things any simpler or easier for me as an HTTP server developer. Initially, we wanted to be as strict as possible when parsing request headers to avoid possible HTTP request smuggling attacks. I don't think allowing LF termination really allows for smuggling, but it is something we had to consider.
I do not support even adding the option to terminate HTTP/1.1 request/response headers with single LFs in HttpClient/Kestrel. That's just asking for problems because it's so uncommon. There are clients and servers out there that will reject headers with single LFs while they all support CRLF. And if HTTP/1.1 is still being used in 2050 (which seems like a safe bet), I guarantee most clients and servers will still use CRLF header endings. Having multiple ways to represent the exact same thing does not make a protocol simpler or easier.
[1]: https://github.com/dotnet/aspnetcore/pull/43202
The Article pages are statically generated and cached, that's not the issue here
There seems to be a memory leak going on with my image rn that only came up yesterday when I did the last update. I suspect rn it's related to https://github.com/dotnet/aspnetcore/issues/54405 and am trying out an older build
the VPS has 8gb of RAM and the blog usually doesn't use more than 500mb even when the blog gets hit by fedi, so there is something dubious going on since it kept running up to 4gb RAM over time and then getting killed by linux
In A Brief Look at the 3DS Cartridge Protocol> Just .GetAwaiter().GetResult() it.
That won’t work with various synchronization contexts, where doing this would cause a deadlock. There’s not much fun in trying to debug such issues.
And now that various libraries only provide async api, or worse an non-async version wrapping the async one with . GetAwaiter().GetResult(), you’ll be in for a treat updating your dependencies.
Async all the way is the answer, although various frameworks still don’t offer async hooks. Recently I ran into this for example trying to write an async validator in blazor, but that’s not possible and you have to work around it [1].
C# 5 introduced async/await almost 12 years ago. And we’re still not “async all the way”.
[1]: https://github.com/dotnet/aspnetcore/issues/40244
In Asynchronous Programming in C#Here's the Microsoft .NET and ASP.NET feature tracking:
Add support for Zstandard to System.IO.Compression:
https://github.com/dotnet/runtime/issues/59591
Support zstd Content-Encoding:
https://github.com/dotnet/aspnetcore/issues/50643
In Chrome Feature: ZSTD Content-EncodingMy favourite one is these two related GitHub issues:
IIS Application Pool Recycle returns unexpected 503
https://github.com/dotnet/aspnetcore/issues/10117
reopen issue #10117 - IIS app pool recycle throws 503 errors
https://github.com/dotnet/aspnetcore/issues/41340
It's been a journey of nearly five years, but I guess... it's about the friends you make on the way, right?
Any year now, Microsoft will fix their only web application framework such that a "Hello World" app doesn't crash.
Soon! Any year now... any year.
In Bug ThreadI agree that WASM is the better option. In my opinion it is however not viable for public-facing sites. The bundle size even if you pull all the tricks is just too big.
I am talking about having to download >1MB in the best case before the site is functional. Simply unusable on slow mobile connections. React/Vue/etc. are often sub 100kB, you can even have something like Preact.js at 3kB if you want.
I don't understand why this is seemingly not given more priority at MS: https://github.com/dotnet/aspnetcore/issues/41909 My prediction is that this will kill off the technology if they don't find a solution.
In ASP.NET Core BlazorShowing the 15 most recent of 79 sources. Enable JavaScript to search and browse every indexed mention.