Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

http set-cookie corruption

I have an issue where a web 'site' has been built that processes srp http APIs.
One of the things I do is a - pbcdatapath = HTTP_Services('GetHTTPCookie', CookieName)

When I test the application using the developers 'web location' a proper value is returned that I have set later in the app.

I got the source for his web service and put on my PC and set IIS with the virtual directory pointing to this folder 'pbc2mobile'
I do localhost/pbc2mobile/login.html and the value returned in pbcdatapath appears to be what I had sent prior in response.

I asked what other settings the developer had made in his IIS and he said he uses a cloud based so does not know how setup.

Attached in the logfile that show what is in the http cookie.

What are all the settings that are needed to be set in IIS to be able srp http frameworks to run properly. I have done rewrite rules.

Hope this is explained well enough - I noticed he does have a javascript login that has this:
When I asked about it he said this:- 'This is stored in the client browser cookie location' - 'http set-cookie and this js cookie both stores in the same location but both are different in nature' - I dont understand that response
Seems to me that will overwrite, but, it doesnt when I use his url.
Sorry, his url calls the same /api / data that I do.

//Store the cookie
function setCookie(cname, cvalue, exdays) {
const d = new Date();
d.setTime(d.getTime() + (exdays * 24 * 60 * 60 * 1000));
let expires = "expires="+d.toUTCString();
document.cookie = cname + "=" + cvalue + ";" + expires + ";path=/";

//Fetch the cookie
function getCookie(cname) {
let name = cname + "=";
let ca = document.cookie.split(';');
for(let i = 0; i < ca.length; i++) {
let c = ca[i];
while (c.charAt(0) == ' ') {
c = c.substring(1);
if (c.indexOf(name) == 0) {
return c.substring(name.length, c.length);
return "";


  • I for one have no idea what this means. In what way is the cookie "corrupted". When I look at the log you posted, the content doesn't look corrupted in the sense that there is garbage data. What am I missing?
  • It should be blank or the 6 characters I post there. That information should not be there so to me it is garbage.
    Definitely is the previous response.
  • It should be blank or the 6 characters I post there.

    Sorry for being dense about this, but what 6 characters are you referring to?

    That information should not be there so to me it is garbage.

    What convinces you that this information should not be there?

    Definitely is the previous response.

    What does the response log that immediately preceded the request log you attached look like?
  • >>but what 6 characters are you referring to?
    CookieName ='pbcdatapath'
    JOB1234 that I put there using - HTTP_Services('SetCookie', CookieName, "JOB1234")

    I assumed that only what I set would go in there, so you are saying it can me anything random.
    Why would I not get null if 'pbcdatapath'= is not there.
    If I am just being silly, then forget it. I will just not use it as I cannot trust it to work for me how I thought it would.
  • Based on that response log, there are no cookies being sent to the client. Here are the only headers in that log:

    Status: 200 OK
    Access-Control-Allow-Origin: *
    WWW-Authenticate: xBasic realm="LAN"
    Content-Type: application/hal+json
    Content-Length: 1133

    As far as whether cookie data "can be anything random", my opinion is that this is a "yes and no" answer. Cookies are not immutable. The client has the ability to modify the value of a cookie as well as add new cookies. You can prove this by using Postman to edit/add a cookie to the request.

    Admittedly, this isn't my area of expertise. My understanding is that as long as you are controlling the client and the server, there should be a high degree of confidence regarding the integrity of the cookie. This is because you would not expect your own client to be modifying the cookie unexpectedly.

    Also, keep in mind that there are always bad actors on the internet. Your data will pass through more than one device before it reaches its destination therefore it is always possible for your data to be manipulated along the way. This is mitigated by encrypting the transmission (HTTPS). You can also add protection to your cookies by using the Secure and HttpOnly attributes.
  • Thank you very much.
    I was not sure what the Secure and HttpOnly attributes were about, so, I will play with that.
  • I recommend researching these on your own first so you know what to expect. There are plenty of Google matches to help you along.
Sign In or Register to comment.