I need to check if a particular URL path exists in the service worker cache.
For example, suppose my URL is:
/myserviceworker/service?a=110&b=70
this URL exists in the cache, but there are many of them with different values of a and b.
Now, suppose I want to refresh all of these URLs, how can I do that?
I want to know how to access the key values from Service Worker cache.
If I know the key, my plan is as follows:
var url = new URL(key);
if(url.pathname === "\/myserviceworker/service")
then refetch the key
But I am not sure how to get the cache key and in what format it is. I mean, is it a string or is it already a URL?
Cache API has a match() method which returns a promise resolving in a Response object if match or undefined if no match exists. The second parameter is an object where you can specify ignoreSearch to not take into account URL parameters.
The ignoreSearch option is actually supported only by Firefox (Chrome status here).
In the other hand, to retrieve all the cache entries, you can use the keys() method.
Related
I try to get user session data in a typo3 flux content element. with {user.first_name} I can access the first name of the user, but this will get cached, meaning alls users will see the name of the first one accessing the page. How can I uncache that or load user session data in this template.
What I already tried:
<f:cache.disable> </f:cache.disable> unfortunately the user variable
are still cached...
<v:render.uncache> To make the user session data
accessible in the partial I need to pass it as a parameter, but the
parameters do get cached :(
<f:security.ifAuthenticated> does only
check for permission, but caches aswell.
Working methods:
adding config.no_cache = 1 or page.config.no_cache = 1 in the typoscript setup works, but I would like to use a solution in flux without typoscript, the USER_INT equival solution should be v:render.uncache, but the argument to be passed is cached as explained above
Thanks for any help
You have to use <v:render.uncache> and fetch the user session data inside the partial.
See https://github.com/FluidTYPO3/vhs/issues/1705
I've read multiple posts of SO regarding the topic.
How to code a URL shortener?
How do URL shortener calculate the URL key? How do they work?
PHP URL Shortening Algorithm
Every posts recommends to store the url in the database. It will return you the id, pass the id to a hash function, returning a tiny id.
My question is what will happen if the same url is requested to shorten it again? Bitly.com returns the same tiny url again for the same url.
What exactly should be the best way to go forward in order to ensure non-duplicate urls??
I'm using Azure ACS in my ASP.net MVC 3 website (hosted in Azure too), the scenario is this:
A user first enters my website and fills a one field form, then they need to chose a provider and login, but first I want to store the field value so when they come back from login I'm able to create a profile with this value for the loged in user.
So I believe when they first enter the site and then leaves to login and enters the site again those are two different sessions am I right? and that's the reason the stored data using session state (through SQL Server) is not present when they come back after login am I right? if this is true what would be the best approach then? if not then I'm doing something wrong storing temp data right?
Thanks
UPDATE:
I have discovered that HttpContext.Application state works keeping the data, still I'm not sure if it's a good idea to use it in a controller considering it's in Azure, will it work on production properly??
You can pass state around in the WS-Federation redirect sequence using the wctx URL parameter. In the action that handles the initial POST request, you should get hold of the form parameter you want to keep, then redirect to you identity provider selection page (this will have to be a custom page) with the form parameter appended to the URL. When the user selects an IP on your page, you can pass the parameter on again using the wctx parameter. The WS-Federation passive requestor profile says that this should be returned to you eventually when the IP redirects the user back to your site.
This has some details
http://msdn.microsoft.com/en-us/library/bb608217.aspx
Edit: To get the wctx parameter out of the request when the user finally comes back to your app. Put something like this in the action code:
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
if (fam.CanReadSignInResponse(System.Web.HttpContext.Current.Request, true))
{
string wctxValue = this.HttpContext.Request.Form["wctx"];
}
My preference is to have the wcxt parameter represent a redirect URL (URL encoded) with your parameter as a query parameter in that so it be a URL encoded version of this:
wctx=https://yourserver/yourapp/yourpage?yourparameter=foo
Then the action that was receiving the redirect from the ACS would simply pull out the value of wctx and do a redirect to it without any more processing. This keeps things simple.
Another approach would be to save whatever data you need to pass around in the Database, and just pass around some ID that refers back to the database record. You'll pass this ID to IP and back through wctx (as Mike mentioned above).
This will solve the issue of limited length of URLs (in case your data is very large). Of course you would need to manage deletion of this data, but this shouldn't be hard.
I have a webscript in alfresco that does something simple: reads a property, and based on its value, creates a json response. Another webscript is in charge of updating this property. However, the response from the original script is sometimes cached, and not for all clients.
So, for one client, I get a current status, and for the other I get the previous state.
The webscript basically reads a property from a node (nodeRef was sent in webscript request):
var status = doc.properties["my:customProp"];
switch (status) {
case "something":
model.prop = "FirstResponse";
break;
case "somethingElse":
model.prop = "SecondResponse";
break;
default:
model.prop = "ThirdResponse";
}
The freemarker template then parses the prop and creates a json output for the response.
Now, this should be simple and straightforward. The use case is as follows:
1. When a user #1 first gets to the doc, the status was set to "something". He got a "FirstResponse", and with a webscript he changed it.
When he then get the document again, he gets the second response.
But if a second client accesses this same node and asks for the response, it still gets the first response, and even more, when I try to read that prop, I get the "old" prop.
So I'm refreshing the script from two clients and reading this property, one client gets one value, the other gets another value.
My only guess (so far) is that this is a caching issue. So, how do I prevent caching? And where did it happen? Hibernate? Some sort of repository cache? How to get rid of it?
check http://wiki.alfresco.com/wiki/Web_Scripts#cache
Well, found the problem here, the prop was defined as d:mltext. So it wasn't cached information, just multilanguage info. I had to extend the model and add a new prop that multilanguage, now all users have the same information.
Why are there GET and POST requests in AJAX as it does not affect page URL anyway? What difference does it make by passing sensitive data over GET in AJAX as the data is not getting reflected to page URL?
You should use the proper HTTP verb according to what you require from your web service.
When dealing with a Collection URI like: http://example.com/resources/
GET: List the members of the collection, complete with their member URIs for further navigation. For example, list all the cars for sale.
PUT: Meaning defined as "replace the entire collection with another collection".
POST: Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.
DELETE: Meaning defined as "delete the entire collection".
When dealing with a Member URI like: http://example.com/resources/7HOU57Y
GET: Retrieve a representation of the addressed member of the collection expressed in an appropriate MIME type.
PUT: Update the addressed member of the collection or create it with the specified ID.
POST: Treats the addressed member as a collection in its own right and creates a new subordinate of it.
DELETE: Delete the addressed member of the collection.
Source: Wikipedia
Well, as for GET, you still have the url length limitation. Other than that, it is quite conceivable that the server treats POST and GET requests differently; thus the need to be able to specify what request you're doing.
Another difference between GET and POST is the way caching is handled in browsers. POST response is never cached. GET may or may not be cached based on the caching rules specified in your response headers.
Two primary reasons for having them:
GET requests have some pretty restrictive limitations on size; POST are typically capable of containing much more information.
The backend may be expecting GET or POST, depending on how it's designed. We need the flexibility of doing a GET if the backend expects one, or a POST if that's what it's expecting.
It's simply down to respecting the rules of the http protocol.
Get - calls must be idempotent. This means that if you call it multiple times you will get the same result. It is not intended to change the underlying data. You might use this for a search box etc.
Post - calls are NOT idempotent. It is allowed to make a change to the underlying data, so might be used in a create method. If you call it multiple times you will create multiple entries.
You normally send parameters to the AJAX script, it returns data based on these parameters. It works just like a form that has method="get" or method="post". When using the GET method, the parameters are passed in the query string. When using POST method, the parameters are sent in the post body.
Generally, if your parameters have very few characters and do not contain sensitive information then you send them via GET method. Sensitive data (e.g. password) or long text (e.g. an 8000 character long bio of a person) are better sent via POST method.
Thanks..
I mainly use the GET method with Ajax and I haven't got any problems until now except the following:
Internet Explorer (unlike Firefox and Google Chrome) cache GET calling if using the same GET values.
So, using some interval with Ajax GET can show the same results unless you change URL with irrelevant random number usage for each Ajax GET.
Others have covered the main points (context/idempotency, and size), but i'll add another: encryption. If you are using SSL and want to encrypt your input args, you need to use POST.
When we use the GET method in Ajax, only the content of the value of the field is sent, not the format in which the content is. For example, content in the text area is just added in the URL in case of the GET method (without a new line character). That is not the case in the POST method.