I have code that is cached this way:
[OutputCache(Duration="3600", Location=OutputCacheLocation.Client)]
Now, I don't exactly know how this output cache works. Where exactly does it keep the copy of a page? And what are the differences between OutputCacheLocation.Client and OutputCacheLocation.Browser?
Where exactly does it keep the copy of a page?
The location of where the cache is stored is determined by Location property of the OutputCacheAttribute. In your case you set Location=OutputCacheLocation.Client so it will keep the cache on the client browser.
And what are the differences between OutputCacheLocation.Client and
OutputCacheLocation.Browser?
OutputCacheLocation.Browser doesn't exist. It's an invalid value. The documentation of the OutputCacheLocation enumeration type contains the possible values along with a description of its usage:
Any - The output cache can be located on the browser client (where the request originated), on a proxy server (or any other server)
participating in the request, or on the server where the request was
processed. This value corresponds to the HttpCacheability.Public
enumeration value.
Client - The output cache is located on the browser client where the request originated. This value corresponds to the
HttpCacheability.Private enumeration value.
Downstream - The output cache can be stored in any HTTP 1.1 cache-capable devices other than the origin server. This includes
proxy servers and the client that made the request.
Server - The output cache is located on the Web server where the request was processed. This value corresponds to the
HttpCacheability.Server enumeration value.
None - The output cache is disabled for the requested page. This value corresponds to the HttpCacheability.NoCache enumeration value.
ServerAndClient - The output cache can be stored only at the origin
server or at the requesting client. Proxy servers are not allowed to
cache the response. This value corresponds to the combination of the
HttpCacheability.Private and HttpCacheability.Server enumeration
values.
Related
Apparently I was under the misconception that GET and POST methods differ in the sense that the query parameters are put in plaintext as a part of the URL in GET method and the query parameters are THERE IN THE URL IN ENCODED(ENCRYPTED) FORM .
However , I realize that this was a grave misconception . And after going through :
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9
and after writing a simple socket server in python and sending it both GET and POST (through form submission) and printing the request in server side
I got to know that only in GET the parameters are there in the URL but in POST the parameters are there in the request body .
I went through the following question as well so as to see if there is any difference in sending a GET and POST at lower level (C-Level) :
Simple C example of doing an HTTP POST and consuming the response
So as in the above question above I saw that there is no special encryption being applied to the POST request .
As such I would like to confirm the following :
1.The insecurities associated with GET and POST are only because of the GET method attaching the parameters in the URL .
For somebody who can have the whole request body , both the GET and POST methods are equally vulnerable .
Over the network , both the GET and POST body are sent with the equal degree of encryption applied to them .
Looking forward to comments and explanations.
Yes. The server only gets to know about the URL the user entered/clicked on because it's sent as the data of the request, after (transport) security has been negotiated so it's not inherently insecure:
you type into a browser: https://myhost.com/a.page?param=value
browser does DNS lookup of myhost.com
browser connects to https port 443 of retrieved ip
browser negotiates security, possibly including myhost.com if the server is using SNI certificates
connection is now encrypted, browser sends request data over the link:
GET /a.page?param=value HTTP/1.1
Host: my host.com
(other headers)
//Probably no body data
---- or ----
POST /a.page HTTP/1.1
Host: my host.com
(other headers)
param=value //body data
You can see it's all just data sent over an encrypted connection, the headers and the body are separated by a blank line. A GET doesn't have to have a body but is not prevented from having one. A POST usually has a body, but the point I'm making is that the data sent (param=value) that is relevant to the request (the stuff the user typed in, potentially sensitive info) is included somewhere in the request - either in the headers or the body - but all of it is encrypted
The only real difference from a security perspective is that the browser history tends to retain the full URL and hence in the case of a GET request would show param=value in the history to the next person reading it. The data in transit is secure for either GET or POST, but the tendency to put sensitive data on a POST centres on the "data at rest" concept in the context of the client browser's history. If the browser kept no history (and the address bar didn't show the parameters to shoulder surfers) then either method would be approximately equivalent to the other
Securing the connection between browser and server is quite simple and then means the existing send/receive data facilities all work without individual attention, but it's by no means the only way of securing connection. It would be conceivably possibly not to have the transport do it but instead for the server to send a piece of JavaScript and a public part of a public/private key pair on the page somewhere, then every request the page [script causes the browser to] makes could have its data individually encrypted and even though an interim observer could see most of the request, the data could be secured that way. It is only decryptable by the server because the server retains the private part of the key pair
Does anyone has any information about s_sess cookie. All I can find is that it's a performance cookie.
The issue here is : My client has 2 websites, one of them is storing the value of query string parameter "cid" in s_sess cookie while the other site is not. Both of them has same adobe analytics code and both sites are on third party cookies.
Many of Adobe's plugins make use of the s.c_r() and s.c_w() (legacy H code) or s.Util.cookieRead() and s.Util.cookieWrite() (AppMeasurement) functions, which are for reading/writing cookies, respectively. Out of the box, you specify a cookie name and it writes to that cookie namespace.
However, Adobe also has a "combined" cookie plugin. With this plugin, all cookie reading/writing with the above functions are instead written to one of two cookies:
s_sess - This cookie is for session scoped "cookies"
s_pers - This cookie is for "cookies" that persist longer than session
So for example, let's say on the following page:
http://www.yoursite.com/index.html?cid=some_code
And in your AA code, you have the following:
// look for cid= param to put into campaign variable
s.campaign = s.Util.getQueryParam('cid');
// use getValOnce plugin to make sure duplicate values do not pop it again
s.campaign = s.getValOnce(s.campaign, 'cid', 0);
Without the combined cookies function, you will see a cookie named "cid" in document.cookies with value of "some_code" set to expire on Session.
But with the combined cookies function, you will not see a cookie named "cid". Instead, you will see a cookie named "s_sess" with a value like this:
// encoded
%20cid=some_code%3B
// unencoded
cid=some_code;
Or, if you use a plugin that makes use of s.c_w or s.Util.cookieWrite for longer than Session, you will instead see the s_pers cookie populated the same way, but with a timestamp value thrown into the mix, e.g.
// encoded
%20cid=some_code%7C1519759520136%3B
// unencoded
cid=some_code|1519759520136;
Multiple "cookies" are separated by (unencoded) "; " (similar to document.cookie)
But why do I see it on one site but not the other?
Assuming your implementation is in fact identical, my guess based on what you posted vs. common implementations is you have code similar to my example above: You grab cid= param for campaign tracking and make use of getValOnce or some other plugin that pushes the value to a cookie, and you went to siteA page with a campaign code (cid= param) but not siteB.
I plan on using Amazon Cloudfront CDN, and there is a URL that I need to exclude. It's a dynamic URL (contains a querystring).
For example, I want to store/cache every page on my site, except:
http://www.mypage.com/do-not-cache/?query1=true&query2=5
EDIT - Is this what invalidating 'objects' does? If so, please provide an example.
Thanks
At the risk of helping you solve the wrong problem, I should point out that if you configure CloudFront to forward query strings to the origin server, then the response will be cached against the entire URI -- that is, against the path + query-string -- not against the path, only, so...
/dynamic-page?r=1
/dynamic-page?r=2
/dynamic-page?r=2&foo=bar
...would be three different "pages" as far as CloudFront is concerned. It would never serve a request from the cache unless the query string were identical.
If you configure CloudFront to forward query strings to your origin, CloudFront will include the query string portion of the URL when caching the object. [...]
This is true even if your origin always returns the same [content] regardless of the query string.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html
So, it shouldn't really be necessary to explicitly and deliberately avoid caching on this page. The correct behavior should be automatic, if CloudFront is configured to forward the query string.
Additionally, of course, if your origin server sets Cache-Control: private, no-cache, no-store or similar in the response headers, neither CloudFront nor the browser should cache the response.
But if you're very insistent that CloudFront be explicitly configured not to cache this page, create a new cache behavior, with the path pattern matching /do-not-cache*, and configure CloudFront to forward all of the request headers to the origin, which disables caching for page requests matching that path pattern.
What's the difference between reload and reloadFromOrigin in WKWebView? Apple's documentation says that reloadFromOrigin:
Reloads the current page, performing end-to-end revalidation using
cache-validating conditionals if possible.
But I am not sure what that really means.
I was interested in this too. Looking at WebKit's source (Source/WebCore/loader/FrameLoader.cpp, FrameLoader::addExtraFieldsToRequest(...) around the if (loadType == FrameLoadType::Reload) conditional) it looks like the key difference is in what extra HTTP header request fields are specified.
reloadFromOrigin() sets the Cache-Control and Pragma fields to no-cache, while a simple reload() only results in in the Cache-Control header field having max-age=0 set.
To work out what this means I looked at the Header Field Definitions section of the HTTP 1.1 spec. Section 14.9.4 'Cache Revalidation and Reload Controls' states:
The client can specify these three kinds of action using Cache- Control request directives:
End-to-end reload
The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request.
Specific end-to-end revalidation
The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional with the client's current validator.
Unspecified end-to-end revalidation
The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validating
conditional; the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional with its current validator.
From my reading of the spec, it looks like reload() uses only max-age=0 so may result in you getting a cached, but validated, copy of the requested data, whereas reloadFromOrigin() will force a fresh copy to be obtained from the origin server.
(This seems to contradict Apple's header/Class Reference documentation for the two functions in WKWebView. I think the descriptions for the two should be swapped over - I have lodged Bug Report/Radar 27020398 with Apple and will update this answer either way if I hear back from them...)
In a rails app / HTML5 app I need to redirect from
http://www.example.com/?
to a canonical:
http://www.example.com/
(The context is an HTML5 web app, where some browsers do not see the two URLs as equivalent, and will therefore request and cache two copies of the same page.)
I can't find any way of getting at the raw request string - Request#original_fullpath() and Request#original_url() have already removed the empty query string.
You can pull the raw url off of request.env["REQUEST_URI"]. This operates at the controller level, and is simply a delegate from rails to the underlying Rack::Request.