Hacker News Reader

Comment by manigandham | Hacker News Reader

HttpClient is fast and efficient, and the built-in cookie container handles all the standard functionality, although many users just read and handle the cookie header directly.

This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?

View on HN

Well, you expect http library to be as good as everywhere else.. like python requests. When library is not updated due to app compatibility issues i would not call it modern. It is good enough for basic use, tho.

HttpClient supports http2, the latest protocol features, has been rewritten in managed code with sockets, and includes advanced handling to balance connection lifetimes with DNS updates. It's about as modern as it gets and we run 10 billion requests per day through this code without issue.

How does a lack of support for an RFC (which is still being revised) that outlines where a cookie should not be accepted in edge cases mean the HTTP library is not modern? Where are you running into this issue in a real app?

> Where are you running into this issue in a real app?

I had discovered few bugs in cookies handling myself, compared behavior to competitors and moved on. If cookies handling is not enough, i came across inconsistent behavior on different platforms: on Windows it uses WinHttpHandler, on Linux its curl lib(if i remember correctly). And they both handle edge cases differently.

HttpClient uses sockets in managed code since .NET Core 2.1 which was released in Oct 2018: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...

There shouldn't be any platform issues unless you're using an even older version or manually forcing it. What bugs in cookie handling did you encounter? This is very widely used code and the team is responsive so if you can document the issues then they can help.

Yeah, comparing it to requests which is:

A.) Not even stdlib

and

B.) Doesn't support async/await

Is an odd choice.

Well, requests is a third party library. I don't like Python's standard library's HTTP APIs. I think that's a common sentiment. Similarly, you can get a solid third party its client for dotnet [1]. .NET core certainly has its shortcomings. I'm going to rattle of a list of other high quality libraries that address the .NET core shortcomings for me personally:

1) Dapper - https://github.com/StackExchange/Dapper

2) DbUp - https://dbup.readthedocs.io/en/latest/

3) Autofac - https://autofac.org/

The Kestrel source code expanded my view of what was possible in C# with respect to low level operations on memory (check out the fixed statement [2]).

A part of me doesn't want to like Microsoft because of their anti-competitive behavior in the past and crappy developer experiences from 10 years ago. Now, I sound like a Microsoft shill because of how good .NET core is.

[1] https://github.com/restsharp/RestSharp

[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

especially since you need to enable the cookie container functionality manually and you can override it by yourself

or use different language with good library that support 8-year old RFC.

C# is a language but .NET is a runtime and standard library. If this issue is really such a problem, you can use any of the dozens of open-source libraries available or just implement your own cookie container that follows this RFC in about a day.

It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.

No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?

Modern workloads refers to the kind of applications commonly built today, like http/json/grpc webservices running in containers.

And yes the HttpClient is modern. Your entire argument so far has been a single RFC issue that is labeled up-for-grabs because it's so minor and doesn't really affect anyone. Claiming the http functionality and the whole stack isn't modern because of it just doesn't add up.

especially since cookiejar is kinda useless. you can't use it with more than a single server, anyway..

You are being over the top and quite frankly ridiculous. I've been using .Net Core in production since its initial release while working for a famous games company (which you probably heard of) and now for a multi billion dollar FinTech firm, and the whole time I have been using HttpClient or libraries using HttpClient for connecting to services/apis.

If your whole reason for not using .Net Core is based around this weird and honestly unimportant edge case, all that tells me is that you have a strange bias against the framework for some other reason and looking to nitpick.

That "8 year old standard" you linked to is just a draft and proposed standard. Nobody implements draft specs in production grade libraries/frameworks. Especially not Microsoft.

Reply on news.ycombinator.com