Flurl: Some cookies in the CookieJar are being ignored when sent in a request

[bgmulinari]

With the recent changes to cookie management in version 3.0 (#506), I noticed a problem when using Flurl to consume the SAP Business One Service Layer. This is an API where the authentication is based on cookies, where I basically do a POST request to perform the login. The response, if successfull, should have 3 cookies that I need to send in the subsequent requests.

I can verify that the login is working as intended, and the 3 cookies are indeed contained in the CookieJar that I receive. However, when using the same CookieJar to perform some other request, only 1 cookie is being sent, which results in an 401 Unauthorized error. Is this a bug or am I doing something wrong? I'm testing the 3.0.0-pre5 version.

Here is my code demonstrating the issue:

[tmenier]

Thanks for trying the prerelease and reporting this. The FlurlCookie extension method ShouldSendTo is perfect for debugging this case. Try calling it on all received cookies, passing the subsequent URL, and if false, note the reason. Something like this (after the first call):

c# foreach (var cookie in jar) { if (cookie.ShouldSendTo(url, our var reason) Console.WriteLine($"{cookie.Name} will be sent."); else Console.WriteLine($"{cookie.Name} will not be sent because {reason}."); }

Once we know why it's not sending we can determine if there's a bug here.

[bgmulinari]

Hey, thanks for the quick answer! The two first cookies seem to be ignored because of their Login path. I'm not sure what to think of this...

[tmenier]

I believe this is the correct behavior by Flurl. If you look for a Path attribute on the 3 cookies, my guess is the first 2 do not have it and the third one does. (It's probably either / or /b1s or /b1s/v1. ) According to the spec, absent of an explicit Path, cookies should only be sent to the same path or sub-path of the one that set the cookie, which in this case is /b1s/v1/Login. Since /b1s/v1 is not sub-path of /b1s/v1/Login, it isn't sent.

[bgmulinari]

As you said, only the ROUTEID cookie has the /b1s Path, the others are empty:

Would you say this is a flaw in the API then?

I guess I can workaround this by rebuilding the CookieJar myself, but it's kind of not ideal, I guess:

var newCookieJar = new CookieJar();

foreach (var cookie in originalCookieJar)
{
    newCookieJar.AddOrReplace(new FlurlCookie(cookie.Name, cookie.Value, cookie.OriginUrl) { Path = "/b1s" });
}

[tmenier]

That's a work-around for the time being. I'm investigating whether I got this wrong.

[bgmulinari]

Hey, @tmenier, something I noticed when testing the API using Postman is that the Path present on all cookies I receive, as shown in the image bellow. Maybe there is a problem when receiving the cookie in Flurl that is making the Path empty in some cases, but I'm not sure.

[tmenier]

I doubt it. I think that's probably a Postman thing. Check the Headers. What did it send in the Set-Cookie headers?

[bgmulinari]

Here it is:

[tmenier]

Still, what Postman is saying could be very telling. There's an algorithm in the spec for determining the default Path in the absence of one being provided. If the default path of a cookie set on /b1s/v1/Login is /b1s/v1, then I've done it wrong in Flurl.

I forgot about it when you first posted this, but this exact scenario was a real dilemma for me a couple months ago. This answer on Stack Overflow was very helpful in implementing some of these scenarios, but as you can see in the comments I questioned whether he got one of the scenarios wrong. This is your exact scenario. Never heard back, assumed I misinterpreted the spec, and went with how he presented it in the answer. I'm starting to think I should have gone with my gut.

[bgmulinari]

This is very interesting, I never put much thought before into how cookies work. As I understood this is what's happening:

I perform a POST to /b1s/v1/Login, which returns me the cookies without a Path. Flurl is then assuming the Path as /b1s/v1/Login as opposed to /b1s/v1. This results in a problem in the subsequent requests like /b1s/v1/BusinessPartners because the cookies are not sent. That's it?

[tmenier]

That's correct, and I'm now convinced Flurl has it wrong. I threw together a little web app that sets a cookie at /a/b/c without specifying a Path and checked if it's sent in requests to /a/b. Here's what some browsers told me (latest versions on Windows 10):

Chrome - yes
Firefox - yes
Edge - yes
Internet Explorer - no

Call me crazy but I trust the first 3 a bit more than IE in the standards department. :)

I'll be fixing this ahead of the official 3.0 release. Thanks again for bringing it up.

[tmenier]

Should be fixed in the latest prerelease. Can you test it? https://www.nuget.org/packages/Flurl.Http/3.0.0-pre6

[bgmulinari]

Tested and confirmed to be working on 3.0.0-pre6:

Thanks for the quick responses and even quicker fix! I look forward to the official 3.0 release, keep up the good work! 👍