setCookie encodes values on iOS

[trackmyapp]

Describe the bug When I use Http.setCookie it encodes the value of the cookie that I put into the options of the function. Then when I want to use a Http.request with the previously set cookie, the cookie is wrong because it is encoded.

To Reproduce let cookie = "75%2c0%2c0%20{801%200%A5}"; const cookieOptions: HttpSetCookieOptions = { url: "https://example.at", key: "cookie", value: cookie }; Http.setCookie(cookieOptions); console.log("cookie from http: ", (await Http.getCookies({ url: 'https://example.at', })) );

Expected behavior The expected console.log would be: cookie from http: –{cookies: [{key: "cookie", value: "75%2c0%2c0%20{801%200%A5}"}. But the console.log shows: cookie from http: –{cookies: [{key: "cookie", value: "75%252c0%252c0%2520%7B801%25200%25A5%7D"}

Desktop (please complete the following information):

• OS: iOS

Smartphone (please complete the following information):

• Device: iPad 6. Generation
• OS: 14.7.1

Additional context My current workaround for iOS is to remove the encoding from the setCookie function in Plugin.swift. In Android it works correctly.

It would be awesome if this bug gets resolved. Was there a reason for the encoding? And if yes, then why is the cookie not decoded in the function setCookie of the CapacitorCookieManager.swift - file.

[gabides]

We have the same issue, it would be nice if this issue was fixed

[steve-allam]

I have a similar issue using a capacitor web app - mine is complex perhaps, but basically loading an iframe with a src url which is served by an old ASP app. We need to set cookies that have come ultimately from the same server, but via a proxied login method. This is part of a process of moving away from the old server.

v0.3.0 of this plugin was in use - working fine, but an upgrade to 1.4 broke things - and it turned out to be the addition of encoding within the setCookie() routine.

I wondered why the routine had encoding in at all - and looking through RFC-6265 (Http state managment mechanism) I don't believe a client library should be doing any encoding of cookie - keys or values. I can see why they might - to stop cookies sent with illegal characters breaking things, but the RFC states:

"To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648]."

So it advises that SERVERs can encode data - values, not keys, and should not must. So it is the servers job to set and encode cookies, and the clients job to faithfully return those cookies. Thus, where a client has to set a cookie - as in my case, ensuring that the server cookie is set on a particular request, it needs to set the same cookie that it was given, and not pass back an encoded version!

In other client libraries, there seems to have been the same request - stop encoding cookies - or allow a switch to turn encoding on/off - or - worse - allow the selection/definition of an encoding algorithm - I don't want a urlencoded cookie when my server uses base64 - right?

The conclusion in one of these was - yeah - after consideration, we shouldn't be encoding/decoding cookies on the client - leave that to the developer that gives us the key/value to ensure that they are encoded (or not) as they wish.

So - my vote would be to stop encoding cookies in client libraries!

Incidentally, the way I got around this was to directly set the cookies, so my own setCookie routine, which used to call Http.setCookie, now looks like this

async setCookie(url,key,value) { // doesn't work as it encodes cookie! //const ret = await Http.setCookie({ url: url, key: key, value: value });

const date = new Date();
const expiresInMillis = 1 * 86400000;
date.setTime(date.getTime() + expiresInMillis);

document.cookie = key + '=' + value + ';expires=' + date.toUTCString() + ';path=/';

}

Hope that helps someone - I assume it might work for both IOS and Android, but not tested there, as I'm only using this on a web project.

Steve