We Keep Coding

Set-Cookie in Response Header not being set in browser

I am having issues with trying to set a cookie from a Response Header, I can see the set-cookie key with all the options that i have specified but for some reason it is not being set in the browser (Chrome).
I am setting the cookie using koajs, and reads as follows:
this.cookies.set(’test-cookie’, ‘valid’, { domain: ‘.test.io’, httpOnly: false, maxAge: 604800000 })
this is what I get in the response:
GET https://api.test.io/conversion
set-cookie: test-cookie=valid; path=/; expires=Mon, 12 Jun 2017 14:23:40 GMT; domain=.test.io;
I have another request (GET https://identity.test.io/identity) that does a similar request and has the same set-cookie response and i can see this cookie in chrome dev tools.
The only difference is api.test.io goes through several redirects (301), however we do not think that is the issue as we still see the set-cookie key in the final response header.
nb: this cookie needs to work across multiple sites which is why we don’t set secure, signed or httpOnly.

My answer is strictly for local testing, but I am putting it here as an answer cause your question is exactly what I searched for before I fixed it.
My php.ini file had the session.auto_start setting set to 0. I set it to 1, and the browser started saving cookies that were in response header. (using WAMP with PHP 7.0.29)

Safari on iOS involving stale $http.get results

I've just noticed that Safari on iOS keeps stale $http.get results in cache, that target my server (REST call).
However, Safari claims a status 200 (not 304), even if result is stale... troubling
I confirm that the issue comes from Safari since it's easy to check the real result through a rest call to the server.
What I do to force Safari to refresh its cache is adding a random parameter:
$http.get('myUrl?rnd=' + new Date().getTime())
Is there a better practice? Probably changing the response headers on the server directly?
My server returns this response header:
HTTP/1.1 200 OK
Server: Cowboy
Date: Tue, 11 Nov 2014 23:52:59 GMT
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 495
Via: 1.1 vegur

Your response doesn't have any cache control headers. According to this answer browsers are free to do whatever they want if there are no cache control headers. In your case Safari on iOS has decided to cache the content even though that isn't what you want.
You could keep using your workaround, or you could add cache control headers in the response to tell Safari not to cache your response.
Note that RFC's might say that responses should not be cached if there are no cache control headers. (I haven't checked). But browsers often have non-standard behavior that you have to work around.
As an aside - early on in my computer networking job I thought that it was OK to not support browsers and webservers that didn't follow the RFCs. I was wrong.

How to fetch images, css, js from cache (with http status 200 (cache) not 304)

I have web page which refers large number of JS, Images files. when teh page is loaded second time, 304 requests goes to the server. I would like to get http 200 (cache) status for cached object rather than 304.
I am using asp.net 4, iis 7.
Setting the Expiry header is not working, it still sends 304 requests. I want http status 200 (cache).
Please let me know if there is any technique for this.

You've said that setting the expiry doesn't help, but it does if you set the right headers.
Here's a good example: Google's library hosting. Here are the (relevant) headers Google sends back if you ask for a fully-qualified version of a library (e.g., jQuery 1.7.2, not jQuery 1., or jQuery 1.7.):
Date:Thu, 07 Jun 2012 14:43:04 GMT
Cache-Control:public, max-age=31536000
Expires:Fri, 07 Jun 2013 14:43:04 GMT
(Date isn't really relevant, I just include it so you know when the headers above were generated.) There, as you can see, Cache-Control has been set explicitly with a max-age of a year, and the Expires header also specifies an expiration date a year from now. Subsequent access (within a year) to the same fully-qualified library doesn't even result in an If-Modified-Since request to the server, because the browser knows the cached copy is fresh.
This description of caching in HTTP 1.1 in RFC 2616 should help.

JS/AJAX browser caching issue

I am working on an eshop with a calculator to calculate your loan. I need some fresh insight on this... imagine this situation:
User clicks on one of the buttons it will do a POST request (jQuery) and fill the required data.
User clicks add to cart and goes to cart
User clicks back button (browser)
Page is loading, server is filling the data in the calculator (default), BUT after its done, browser fills the JS data from cache and a funny thing happens. The data gets combined and when user adds the product to his cart he will get wrong, but valid price. Valid part is what server fills and the rest comes from cache.
I have tried using meta tags to prevent caching, I have told jquery to not cache the POST request and even in my responder, I have multiple headers that say - DO NOT CACHE. Yet still the POST data gets cached and I have no idea how to turn it off or refresh it or whatever... When I look at the headers that come back with the json data, header expires is set to year 2099, even though I have said it should be a year from past. Apart from that, I really dont know what could be causing this issue.
Here are the headers set in responder and what gets back:
header("Expires: Mon, 26 Jul 1999 05:00:00 GMT" );
header("Last-Modified: " . gmdate( "D, d M Y H:i:s" ) . "GMT" );
header("Cache-Control: no-cache, must-revalidate" );
header("Pragma: no-cache" );
header("Content-type: text/x-json");
This gets back (from firebug):
Date Fri, 17 Sep 2010 08:39:38 GMT
X-Powered-By PHP/5.1.6
Connection Keep-Alive
Content-Length 126
Pragma no-cache
Last-Modified Fri, 17 Sep 2010 08:39:38GMT
Server Apache
Content-Type text/x-json
Cache-Control no-cache, must-revalidate
Expires Mon, 26 Jul 2099 05:00:00 GMT
Note: when I disable cache in browser preferences it works like a charm.
Any ideas are welcome!
Edit:
I have tried the dummy few hours before, but that doesnt solve it. To put it simple the whole problem is that when user clicks back button, the page wont refresh, but its read from cache, or at least the data that came from ajax are cached and get filled.
So basically I need to refresh the page in a smart way when user clicks back button. Note that cookies are not an option, because (maybe a small percentage, but still) some people dont have cookies allowed.

If you want to handle back/forward buttons, one way is to use bbq plugin for jQuery, which is capable of modifying the # part of the url.
Thus you will be able to hook up to back/forward events and have complete control over what's executed and when, firing whichever Ajax requests you need.
It means though that you'll have to change the concept of your page flow - no direct posting to the server, only via ajax, + client side rendering via some template mechanism.
This is somewhat of emerging trend, examples being google with their instant search.

Add a dummy parameter to all your ajax queries '&t='+new Date().getTime();
This will ensure that a fresh request is sent every time.

Solve it some with a little hack, since it looks like pure browser issue.

Missing cookie in IE 6, 7,and 8

I'm sending 2 cookies to the browser. One is a browser identifier which expires in 1 year, and the other is a session tracker without an expiration. The response headers for a fresh request look like this
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-XSS-Protection: 0
ETag: "b502a27282a5c621f34d522c3fcc8e3e"
Set-Cookie: bid=ahFmaXJld29ya3Njb21wdXRlcnIPCxIHQnJvd3NlchimigcM; expires=Fri, 12-Aug-2011 05:21:55 GMT; Path=/
Set-Cookie: rid=1281569589; Path=/about
Expires: Wed, 11 Aug 2010 23:33:09 GMT
Cache-Control: private, max-age=345600
Date: Wed, 11 Aug 2010 23:33:09 GMT
I'm trying to access both cookies from JavaScript on the page.
In Firefox and Chrome document.cookie gives me this
"rid=1281568223; bid=ahFmaXJld29ya3Njb21wdXRlcnIPCxIHQnJvd3Nlchj2nAYM"
In IE6, IE7, IE8 document.cookie only gives me this
"bid=ahFmaXJld29ya3Njb21wdXRlcnIPCxIHQnJvd3Nlchj2nAYM"
Is the 'path' attribute in my rid cookie throwing off IE or would it be the missing expiration date (which I thought was supposed to be optional)? I assume it is not the fact that I'm setting more than 1 cookie, because that's done all the time.

IE will only allow you access to those cookies if you are in a subdirectory! So if you set the cookie's path to be /about, and your page is actually /about then you cannot access it.
So it seems for IE you can access the cookie on pages beneath /about like /about/us but not on a page that is /about itself. Go figure :/

Alexis and Rishi I think have this spot on. And this is the only place on the web I've found this information on how IE treats cookies with paths. And what a ball ache! IE strikes again.
Incidentally, in IE 11 at least, it performs a 'starts with' comparison on the full path, so setting a cookie with a path of '/abou' can be accessed on the '/about' page. Though in my current project, this is little consolation, as I'm not in the position to make the assumption that taking one character off the end of the path will reliably identify unique paths in a site.

I also am having a similar issue with IE. I'm setting three cookies without a path (so assumed to be "/"). I am running in a dev envronment on my own machine. When I open the page as http://localhost/page.aspx, I get the expected result and my javascript can find the cookies, however, if I load the same page as http://mymachine.mydomain.com/page.aspx I can watch (in the debugger) the same three cookies being added to the response, but when I get to the javascript function that looks for them, all my cookies are null. Needless to say, this works ok on FireFox.