An example from MDN for how to set cookies is the following Set-Cookie Header:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
In most of the places I've seen, there's no semicolon at the end. I'm wondering, is it ok to have a trailing semicolon? Something like this:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly;
I'm just curious, what are the RFCs saying and how are the different browsers treating it, do they all accept it?
Related
I have a page the includes an iframe.…
<!DOCTYPE html>
<html>
<body>
<!-- … -->
<iframe
src="/assets/js/pdfjs/web/viewer.html?file=2021-09-12_1200-file.pdf#zoom=page-width"
style="..."
></iframe>
<!-- … -->
</body>
</html>
That includes the following response headers…
HTTP/1.1 200 OK
Date: Tue, 26 Oct 2021 11:02:17 GMT
Server: Apache/2.4.38 (Debian)
X-Powered-By: PHP/7.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-DEBUGKIT-ID: 77761443-2882-4882-b0e1-01eea68deded
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2349
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
If I change the file path in the iframe src attribute (e.g /assets/js/pdfjs/web/viewer.html?file=2021-10-26_1200-file.pdf#zoom=page-width - note the new timestamp), and reload the page, the old file is still returned, rather than the new one, despite the Cache-Control: no-store, no-cache, must-revalidate header.
Debugging the requests recevied by the server, I can see…
The parent page is requested and returned with the headers as above (with new Date & X-DEBUGKIT-ID header values), and the correct, updated iframe src value.
The iframe page is being requested with the original filename, rather than the new one (I'm assuming from the cached page).
If I reload using Cmd+Shift+R (to ignore the browser cache), then the correct iframe document is loaded.
What am I missing in this setup that is causing the page to be cached? I thought that the Cache-Control header we have should be sufficient here.
If I add a random query string to the parent page this correctly loads new documents, but I feel this is a hack that should not be needed.
I've also tried adding a Etag header containing a random string that's different for each request, but this seems to have no effect on the browser caching.
I am trying to add an IFrame to a page.
The page:
https://www.homedepot.com/order/view/tracking
The code I'm using to add this IFrame:
function createElementFromHTML(htmlString) {
var div = document.createElement('div');
div.innerHTML = htmlString.trim();
// Change this to div.childNodes to support multiple top-level nodes
return div.firstChild;
}
element = createElementFromHTML(`<div id='testing-iframe'>
<iframe src='chrome-extension://zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/index.html'></iframe>
<div>`)
document.body.appendChild(element)
Now, notice the URL starts with chrome-extension://. Different protocol.
On the above homedepot.com page, when I inspect #testing-iframe, I see no IFrame. It's like the browser rejects the element.
On most other websites on the internet, such as https://example.com/, the IFrame element shows on inspection (no content though, as this is a dummy URL).
Please see screenshot:
See, on example.com I do get an IFrame. On homedepot.com I don't.
Another thing to point out, as said earlier this happens when I'm using a different protocol, chrome-extension. But, when I'm using an HTTPS URL such as https://www.texasauto.com/ it DOES WORK, on both pages.
So far regarding the problem.
My question is: What's causing it?
I assume this is some HTTP header.
First I was suspecting the Strict-Transport-Security header.
So, I tried to disable it with another extension, but it didn't fix it.
Then I tried to disable more headers, and also add the Access-Control-Allow-Origin: * header, yet it didn't work.
Any idea what's causing the problem?
Edit: Headers returned by homedepot.com:
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: POST, GET, OPTIONS, DELETE
access-control-allow-origin: http://localhost:8081
access-control-max-age: 0
cache-control: max-age=0, no-cache, no-store
content-encoding: gzip
content-language: he
content-type: text/html;charset=UTF-8
date: Sat, 29 May 2021 22:16:06 GMT
expires: Sat, 29 May 2021 22:16:06 GMT
pragma: no-cache
server-timing: cdn-cache; desc=MISS
server-timing: edge; dur=153
server-timing: origin; dur=75
set-cookie: AKA_A2=A; expires=Sat, 29-May-2021 23:16:06 GMT; path=/; domain=homedepot.com; secure; HttpOnly
strict-transport-security: max-age=86400; includeSubDomains; preload
vary: Accept-Encoding
x-akamai-transformed: 9 153137 0 pmb=mTOE,1mRUM,2
x-application-context: orders-purchases-ui:prod:8080
x-content-type-options: nosniff
x-device-type: desktop
x-frame-options: SAMEORIGIN
x-proto: secure
x-tm-zone: us-east4-a
x-xss-protection: 1; mode=block
I found this article where it explains how to set a cookie using only HTML.
He use http-equiv attribute on the <meta> in the <head> of an HTML document:
<meta http-equiv="set-cookie" content="___________">
Now I have read about HTML < meta> http-equiv Attribute but
I could not understand how to use it for set a cookie.
Someone can explain to me if you can use this method for set cookie or that guide is just a joke?
I tried this but HolidayGlaze cookie has not been saved.
<meta http-equiv="set-cookie" content="HolidayGlaze=Good%20yummies; expires=Sat, 25-Nov-2023 12:00:00 GMT; domain=.example.com; path=/; secure; httponly;">
P.S. I read also about Differences Between HTML 4.01 and HTML5 syntax so my question is about the correct syntax for HTML5.
You used to be able to set cookies using a meta tag, however browsers are moving away from that in favour of HTTP headers, or document.cookie.
If you try to set a cookie using meta tags in Chrome, you will get a warning and/or error (depending on your version). The feature has been deprecated in M63, and completely removed in M65.
[Deprecation] Setting cookies via <meta http-equiv='Set-Cookie' ...> no longer works, as of M65. Consider switching to document.cookie = ..., or to Set-Cookie HTTP headers instead. See https://www.chromestatus.com/feature/6170540112871424 for more details.
Blocked setting the Example cookie; path=/; expires=Friday, 24-Mar-18 10:00:00 GMT cookie from a <meta> tag.
I would imagine that other browsers also have this feature deprecated/removed, or will follow suit shortly with chrome.
You can read more about the deprecation of this feature here: https://bugs.chromium.org/p/chromium/issues/detail?id=767813
Don't set cookies in HTML with meta http-equiv="set-cookie". It's outdated and has no effect in modern browsers that follow the current HTML5 standard (it's non-conforming in HTML5).
When you are in the development stage it's a bit embarrassing to constantly remind your clients to clear the cache or to ask them to "refresh the page a bunch of times."
Is there a setting that I, the developer, can set in nginx or as a meta tag in the HTML to force all browsers to stop caching my page?
Theoretically, according to Difference between Pragma and Cache-control headers? and also http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32, the following may be sufficient, in nginx:
add_header Cache-Control no-cache;
In practice, you might have to specify some extra directives; it would seem like using the expires directive should be sufficient, which will automatically add the Cache-Control header as above, too:
expires -1;
Try setting these headers:
"Cache-control: no-store, no-cache, must-revalidate"
"Expires: Mon, 26 Jun 1997 05:00:00 GMT"
"Pragma: no-cache"
"Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"
This will prevent the browsers from cashing the pages.
I generate a captcha image (as a .bmp) on the fly with a server side script (.asp).
It is included in a page as follows:
<iframe id="commentCaptcha" height="20px" width="50px" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" src="/inc_captcha.asp">
Everything works as it should.
The problem/Question is that I get the following warning in the google chrome console:
Resource interpreted as Document but transferred with MIME type image/bmp: "/inc_captcha.asp".
Here are the actual raw headers returned from the server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: image/bmp
Expires: Sun, 13 Jan 2013 03:11:36 GMT
Server: Microsoft-IIS/7.5
Date: Sun, 13 Jan 2013 03:12:36 GMT
Connection: close
Is there any way I can prevent this warning?
Setting the source of the iframe to a non-document mine-type is a little strange and not really the usual way of doing it.
Instead the iframe should have the src set to a text/HTML document, your image being an <img> within that document.
If it's just the image you're after, use the <img> tag in the parent document and dont use an iframe at all.