I checked the docs but couldn't find anything about Cache-Control. I wish to set the following header:
Cache-Control: no-cache, max-age=0
If you know a workaround please let me know. Many thanks!
Check here changing the value to 0 to disable or 1 to enable directly in /etc/config/luci
config internal 'ccache'
option enable '1'
By the way, thats for luci running uhttpd. Any other parameters you need to fiddle with /etc/config/uhttpd settings described here https://openwrt.org/docs/guide-user/services/webserver/uhttpd
Related
I have 2 questions.
1.What happens if response header contains x frame options as hoth sameorigin and deny? Will it allow iframe from same origin?
What happens if I set x frame options in both in IIS and in my application? Will it leads to 2 x frame options?
This could depend on the browser and the order of headers, but most likely the strictest value will be used. You will test with various browsers and configurations.
Yes. Note that if you set the same header in multiple levels in IIS your application will fail to start, but it will work if you set it in code and as a response header in IIS.
How do you set/allow cross origin in AngularDart.
I have tried just to set it in the index.html, and looked for it i code?
Like:
.headers["X-FRAME-OPTIONS"] = "ALLOW-FROM http://http://x.x.x.x/mypath"
I am forwarding from a domain: subdomain.domain.com
Thats is why I think I need to ALLOW-FROM x.x.x.x/mypath.
It works without <subdomain>.domain.com but I need the subdomain.
I get:
Refused to display 'http://x.x.x.x/mypath' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
The X-Frame-Options HTTP response header
which means this is set on the server on responses, not by the client.
There is no point setting that in Angular.
I have a grails 2.2.4 application. I wanted to enable CORS
So I installed cors plugin by having the following line in build config.
plugins {
runtime ':cors:1.1.8'
}
Then in the config.groovy
cors.headers = ['Access-Control-Allow-Origin': '*']
But after this when I run the application, CORS in not enabled. So I debugged the CORS plugin. The issue seems to be in CorsFilter class in the following method
private boolean checkOrigin(HttpServletRequest req, HttpServletResponse resp) {
String origin = req.getHeader("Origin");
if (origin == null) {
//no origin; per W3C spec, terminate further processing for both preflight and actual requests
return false;
}
The origin parameter in the above line is always null as the request does not have the parameter 'Origin'. Is there something i'm doing wrong? I'm not looking for the answer which says add a manual header with the name "Origin" since that is not exactly a proper fix
I'm quite new to CORS so appriciate the help.
In addition to Access-Control-Allow-Origin, and in addition to setting the Origin header on request, you probably need to specify these response headers as well:
Access-Control-Allow-Headers: accept
Access-Control-Allow-Headers: origin
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Method: GET
Access-Control-Allow-Method: POST
Also make sure you respond to HTTP OPTIONS requests with these headers and a blank 200 OK response.
For now, let's assume that RestClient is sending the Origin header properly. It may still be getting stripped by your application. You can prevent this using the Access-Control-Allow-Headers: Origin header.
Most of the problems I have had with my web services is that the right headers are being sent, but they are stripped from the message by my web server. So I tend to adopt a shotgun approach of "allow everything" and then one by one remove what I don't need. My allow-headers header usually is pretty long and I end up having to include stuff like Content-Type, X-Requested-With and other junk before my requests will finally go through.
I further recommend that you test using something besides RestClient, if only as a sanity check. I use Postman, a free Chrome app, for all my messaging tests. It looks to me like the problem is with RestClient not sending the proper Origin header.
I put code from end of this article to my MVC controller method:
http://msdn.microsoft.com/en-us/library/windowsazure/gg680299.aspx
I configured cname for cdn and all working fine except I feel that cdn not caching :)
There is CDN url
http://cdn.services.idemkvrachu.ru/services/BranchLogo/82f204fe-bb1d-4204-b817-d424e1284b17/E0F4F2AE-B6C2-4516-BE7C-59B649E2C5AC?lastUpdated=635169430040919922&width=499
And this is original url
http://prm.idemkvrachu.ru/cdn/services/BranchLogo/82f204fe-bb1d-4204-b817-d424e1284b17/E0F4F2AE-B6C2-4516-BE7C-59B649E2C5AC?lastUpdated=635169430040919922&width=499
This is my code:
Response.Cache.SetExpires(DateTime.Now.AddDays(14));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetLastModified(blob.ChangDateOfs.DateTime);
return File(bytes, format);
When I checked timings receiving picture from original link and cdn - I found that timings higher on cdn.
Also I was trying change blob.ChangDateOfs and comparing Last-Modified header from cdn response: it immediately changes.
What's wrong with my code? Maybe this header breaks cdn cache Cache-Control public, no-cache="Set-Cookie" ?
To troubleshoot caching issues the first thing you want to do is validate if your content is actually getting cached or not.o
To do this you can add the X-LDebug header with a value of 2. An example of doing this against your endpoint with the relevant portions of output included:
C:\Azure\Tools\wget\bin>wget -S --header "X-LDebug:2" http://cdn.services.idemkvrachu.ru/services/BranchLogo/82f204fe-bb1d-4204-b817-d424e1284b17/E0F4F2AE-B6C2-4516-BE7C-59B649E2C5AC?lastUpdated=635169430040919922&width=499
Cache-Control: public, no-cache="Set-Cookie"
Set-Cookie: ASP.NET_SessionId=nnxb3xqdqetj0uhlffdmtf03; path=/; HttpOnly
Set-Cookie: idCity=31ed5892-d3cb-45eb-bd4f-526cd65f5302; domain=idemkvrachu.cloudapp.net;
X-Cache: MISS from cds173.sat9.msecn.net
As you can see, you are setting the Cache-Control header to no-cache="Set-Cookie", and then are setting a cookie. This is telling the CDN to not cache the content. Since your code is only setting the cache control to Public I assume that you have a setting in your web.config or aspx page that is modifying the cache control header to add the no-cache="Set-Cookie".
I am currently developing an API where size matters: I want the answer to contain as few bytes as possible. I optimized my JSON answer, but rails still responds with many strange headers
HTTP/1.1 200 OK
Server: nginx/0.7.67 # Not from Rails, so ok.
Date: Wed, 25 Apr 2012 20:17:21 GMT # Date does not matter. We use ETag Can I remove this?
ETag: "678ff0c6074b9456832a710a3cab8e22" # Needed.
Content-Type: application/json; charset=utf-8 # Also needed.
Transfer-Encoding: chunked # The alternative would be Content-Length, so ok.
Connection: keep-alive # Good, less TCP overhead.
Status: 200 OK # Redundant! How can I remove this?
X-UA-Compatible: IE=Edge,chrome=1 # Completely unneded.
Cache-Control: no-cache # Not needed.
X-Request-Id: c468ce87bb6969541c74f6ea761bce27 # Not a real header at all.
X-Runtime: 0.001376 # Same goes for this
X-Rack-Cache: invalidate, pass # And this.
So there are lots of unnecessary HTTP headers. I could filter them in my server (nginx), but is there a way stop this directly in rails?
You can do this with a piece of Rack middleware. See https://gist.github.com/02c1cc8ce504033d61bf for an example of to do it in one.
When adding it to your app config, use something like config.middleware.insert_before(ActionDispatch::Static, ::HeaderDelete)
You want to insert it before whatever the first item in the list that displays when you run rake middleware, which in my case is ActionDispatch::Static.
http://guides.rubyonrails.org/rails_on_rack.html may be somewhat helpful if you haven't been exposed to Rack in the Rails context before.
Another option, since you're using Nginx, is the HttpHeadersMoreModule. This will allow you to have fine-grain control of exactly which headers are sent down the wire.
In your case, you'd specifically want to use the more_clear_headers directive, as such:
more_clear_headers Server Date Status X-UA-Compatible Cache-Control X-Request-Id X-Runtime X-Rack-Cache;
This also clears the Server header, since it's not really necessary, and if you're trying to save bytes, every little bit helps.
This module does require you to compile Nginx on your own, but that really shouldn't scare you. Nginx is very easy to compile, just follow the installation instructions.
I agree that both solutions presented by x1a4 and Stephen McCarth are good.
Ideally you should definitely use the HttpHeadersMoreModule however if someone is fan of native Ubuntu NginX package with security updates like I am, (or you don't have time for that, or just lazy) you don't necessary need to do that.
Another way is to use proxy_hide_header
server {
location #unicorn {
# ...
proxy_hide_header X-Powered-By;
proxy_hide_header X-Runtime;
# ...
}
}
note: #unicorn is just upsteram server, the location can be whatever /, /assets, ..
Now one argument against this solution is if you use several server blocks inside configuration that you need to specify proxy_hide_header to each one of them. Well yes but you can just create file and include it
# /etc/nginx/sites-enabled/my_app
server {
location #unicorn {
# ...
include /etc/nginx/shared/stealth_headers
# ...
}
}
# /etc/nginx/shared/stealth_headers
proxy_hide_header X-Powered-By;
proxy_hide_header X-Runtime
So why I think this solution is better than to use the middle-ware solution as presented by x1a4 ?
I had similar middle-ware solution before and it was working fine for couple of months. Then one day we stopped receiving Exception errors by exception monitoring tool party_foul gem. Long story short Middlewares are tricky, we done some code changes and this middleware was throwing exception, but it was throwing exception that was not caught with middleware that was suppose to monitor exceptions. So yes the whole thing is my bad, I should keep better eye on my code not doing stupid stuff, hewever I had unpleasant experience that is hard to erase, so I'm just recommending if you can rather to handle this on NginX level, not on middle-ware level
+ it make more sence if your NginX is handling several configurations (you don't have to update several applications if some change)