runtime: [Cookie] HttpClient does not properly parse all Set-Cookie headers
Hello,
I’m currently trying to build a .Net Core application that automates some HTTP requests.
In the first request I receive several cookies which should be sent back to the server on the second request.
For demonstration purposes I have created a small PHP script that sends some Set-Cookie
headers similar to the style I receive them from the actual application.
The source code of this script is https://gist.github.com/Nothing4You/6623cda16eb2c2c5b4d3d9106b95a6ce. You can find a live version at https://hosting.rep.pm/cookietest.php.
I have tested the script using a web browser (Firefox), curl (in a linux shell) aswell as using python requests, which all handle cookies and show me the expected output in the second request:
Cookie[test1]: test1value
Cookie[test2]: test=2&value=2
Cookie[test3]: $test-3
Cookie[test4]: test4
However, if I try to do the same thing using System.Net.Http.HttpClient
it only sets the 2 out of 4 cookies.
According to Visual Studio I’m using SDK version 1.1.1. HttpClient is the following version:
Assembly: System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Assembly location: .nuget\packages\system.net.http\4.3.0\ref\netstandard1.3\System.Net.Http.dll
Example code: https://gist.github.com/Nothing4You/c04af6781f8520efb4921ef144733731
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 15 (9 by maintainers)
RFC2965 doesn’t seeem to be relevant for Set-Cookie. In RFC2109 I found the following:
However, as already written in my original post, firefox, curl and python-requests all support this method just fine, so I believe there should be a way to use the appearently commonly accepted way with .NET aswell.
According to RFC2109 is obsoleted by RFC2965, which in turn is obsoleted by RFC6265. RFC6265 is in the state
PROPOSED STANDARD
, which according to wikipedia usually means it should be fine to be used in production code (correct me if I’m wrong).This RFC has the relevant part:
This would just strip a leading dot and parse domains the same way it does now with a leading dot.