Could you tell me how can I uncache the default home page in Rikulo Stream? By home page I mean the main domain (xxx.xxx.com) with no sub path (/xxx), not even including '/'. The urimapping setting doesn't allow me to set a filter for a path that not start with '/', '.', '[' or '(' and (.*) is not working for me, (cache-control is still set to max-age=2592000 for the default home page).
Is it a static page (e.g., index.html) or a RSP page?
If it is RSP, you can specify the header(s) you like. For example,
[:header
Cache-Control="no-cache, must-revalidate, no-store, private, max-stale=0, max-age=0, post-check=0, pre-check=0"
Expires="0" Pragma="no-cache"]
If it is static, there is no direct way to override max-age, ETAG, and related headers. But, there is a few alternatives. First, you can implement your own resource loader).
Second, you implement a handler to set the header and include the real page. Assume you mapped HTML files under /s:
uriMapping: {
r"/s/.*\.html": (HttpConnect connect) {
connect.response.headers..contentType = "text/html"
..add("Cache-Control", "no-cache"); //also other headers
return connect.include(connect.request.uri.path.substring(2));
}
If a page is included, it won't update the headers.
Of course, you can implement your HTML file in RSP. Then, you got the total control. Plus, you can use the script tag to generate a proper link easily (which includes a simple version control).
Related
Background:
Let's have a WebAssembly (wasm) originating from .net code.
This wasm uses HttpClient and HttpClientHandler to access a backend API at https://api.uri.
The actual backend API location might change in time (like https://api.uri/version-5), but there is still this fixed endpoint, which provides redirection (3xx response) to the current location (which is in the same domain).
The API allows CORS, meaning it sends e.g. Access-Control-Allow-Origin: * headers in the responses.
In the normal (non-wasm) world, one just:
Plainly GETs the https://api.uri with no additional headers (CORS safe).
Retrieve the Location: header (containing e.g. https://api.uri/version-5) from the 3xx response as the final URI.
GETs/POSTs the final URI with additional headers (as needed, e.g. custom, auth, etc.).
Note: In ideal world, the redirection is handled transparently and the first two steps can just be omitted.
Although in the wasm world:
You are not allowed to (let the wasm/browser) send the OPTIONS pre-flight requests to a redirecting endpoint (https://api.uri).
You can't send any non-cors headers, when wanting to prevent pre-flight requests (reason for two stages, plain and full, described above).
You can't see the Location: header value (like https://api.uri/version-5) when trying the manual redirection (HttpClientHandler.AllowAutoRedirect = false), because the response is just artificially crafted with HTTP status code of 0 and ReasonPhrase == "opaqueredirect" - adoption to browser's Fetch API. What a nonsense! #1...
You can't see the auto-followed Location: header value in response.RequestMessage?.RequestUri, when trying the (default) automatic redirection (HttpClientHandler.AllowAutoRedirect = true), because there is still the original URI (https://api.uri) instead of the very expected auto-followed one (https://api.uri/version-5). What a nonsense! #2...
You can't send the full blown request with all the headers and rely on the automatic redirection, because it would trigger pre-flight, which is sill not allowed on redirecting endpoint.
So, the obvious question is:
Is there ANY way, how to handle such simple scenario from the Web Assembly?
(and not crash on CORS)
GET https://api.uri => 3xx, Location: https://api.uri/version-5
GET https://api.uri/version-5, Authorization: Basic BlaBlaBase64= ; Custom: Cool-Value => 200
Note: All this has been discovered within the Uno Platform wasm head, but I believe it applies for any .net wasm.
Note: I also guess "disabled" CORS (on the request side, via Sec-Fetch-Mode: no-cors) wouldn't help either, as then such request is not allowed to have additional headers/methods, right?
I have a requirement when click on hyper link details should load in the child window.
Following is the code:
<a onclick="openChildWindow('http://xx.xxx.xx...');return false;">View details</a>
function openChildWindow(url)
{
"use strict";
var child = window.open(url, defaultWindowName);
child.focus();
}
as per the security reasons we need to show response header cache-control attribute value as "no-cache, no-store, max-age=0" for tre requested URL passed in window.open
Java side we are resetting the header value to "no-cache, no-store, max-age=0"
Here comes my problem/issue
When I click on hyper link on MS Edge browser in network tab I see two requests of same URL which passed in the window.open one requst response is 200 and another is 302.
for 200 status response header value is setting as expected "no-cache, no-store, max-age=0"
for 302 I see response header cache-control header values is private.
Can someone helps me why in edge browser I see two requests why 302 default value is private. How can I reset this value to "no-cache, no-store, max-age=0" or how can I avoid this 302 request/redirect URL triggered.
How can I reset this value to "no-cache, no-store, max-age=0"
In my opinion, we can't set it header through the window.open method. You could add it from the server side. Please refer to this article.
how can I avoid this 302 request/redirect URL triggered.
Please check this article:
302 code the typical use case: The Web page is temporarily not available for reasons that have not been unforeseen. That way, search engines don't update their links.
So, please check the request website, make sure it is available.
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 developing an application in rails which requires checking whether a sitemap of the entered website's URL exists or not? For Eg if a user enters http://google.com then it should return "Sitemap present".I have seen for solutions that usually websites have either /sitemap.xml or /sitemap at the end of their URL.So i tried putting a check for this using typhoeus gem, checking response.code for the URL(like www.google.com/sitemap.xml OR www.apple.com/sitemap) that if it returns with a 200 or 301, then sitemap exists, else not.But i have found that some sites return a 301 even if they dont have a sitemap, they redirect it to their main page(For Eg http://yournextleap.com/sitemap.xml), hence i don't get a conclusive result.Any help would be really great.
Here is my sample code to check for sitemap using typhoeus :
# the request object
request = Typhoeus::Request.new("http://apple.com/sitemap")
# Run the request via Hydra.
hydra = Typhoeus::Hydra.new
request.on_complete do |response|
if response.code == 301
p "success 301" # hell yeah
elsif response.code == 200
p "Success 200"
elsif response.code == 404
. puts "Could not get a sitemap, something's wrong."
else
p "check your input!!!!"
end
The HTTP response status code 301 Moved Permanently is used for
permanent redirection. This status code should be used with the
location header. RFC 2616 states that:
If a client has link-editing capabilities, it should update all references to the Request URI.
The response is cachable.
Unless the request method was HEAD, the entity should contain a small hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting.
I don't think its fair for you to assume that a 301 Response indicates that there was ever a sitemap. If you're checking the existence of a sitemap.xml or a sitemap directory then the correct response to expect is a 2XX.
If you're insistent on assuming that a 3XX request indicates a redirect to a sitemap, then follow the redirect and add logic to check the url of the page (if its the homepage) or the content of the page to see if it has XML structure.
Sitemap may also be compressed to sitemap.xml.gz -- so you may have to check for that filename too. Also, it may have an index file that points to many other sub sitemaps which also may be named differently.
For examples in my project I have:
sitemap_index.xml.gz
-> sitemap_en1.xml.gz (english version of links)
-> sitemap_pl1.xml.gz (polish version of links)
-> images_sitemap1.xml.gz (only images sitemap)
Websites ping search engines with those filenames, but sometimes they also may include them in the /robots.txt file, so you may try hunting for them in there. For example http://google.com has this at the end of their file:
(See how weird sitemaps' names can be!)
Sitemap: http://www.gstatic.com/s2/sitemaps/profiles-sitemap.xml
Sitemap: http://www.google.com/hostednews/sitemap_index.xml
Sitemap: http://www.google.com/ventures/sitemap_ventures.xml
Sitemap: http://www.google.com/sitemaps_webmasters.xml
Sitemap: http://www.gstatic.com/trends/websites/sitemaps/sitemapindex.xml
Sitemap: http://www.gstatic.com/dictionary/static/sitemaps/sitemap_index.xml
About 301: you may try spoofing as a Google Bot or other crawler. Maybe they redirect everyone except robots. But if they redirect everyone, there's nothing you can really do about it.