When I test my site using http://www.webpagetest.org/. It says that I have not set cache expiration header on the home page. When I curl, I see it is set:
HTTP/1.1 200 OK
Date: Wed, 23 Mar 2016 22:31:17 GMT
Server: Apache/2.2.22 (Ubuntu)
Cache-Control: max-age=691200, public
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 1; mode=block
X-Request-Id: aa9fc904-2af6-4649-bbb2-dfc308172c08
ETag: W/"0011b34ba2dd655ce7380a1014310370"
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.010013
X-Content-Type-Options: nosniff
X-Powered-By: Phusion Passenger 5.0.25
Set-Cookie: request_method=HEAD; path=/; secure
Set-Cookie: _lafon_session=V21Yc1RlSUlRPT0%3Ddaea; path=/; secure; HttpOnly
Status: 200 OK
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Any ideas on why webpagetest.org thinks the header is not set?
http://www.webpagetest.org/ wrongly expects Expires header to be set, forgetting about full analog with higher priority - max-age.
Everything is ok with your site.
Related
We are having a weird issue where sometimes the browser will decide to use port 80 for HTTPS.
The flow looks like this when it's not working (copied from network devtools):
Flow with port 80 as remote address
1st request:
Request URL: http://app1.test/
Request Method: GET
Status Code: 307 Temporary Redirect
Remote Address: :80
Response headers
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://app1.test/
Non-Authoritative-Reason: HSTS
2nd request
Request URL: https://app1.test/
Request Method: GET
Status Code: 302 Found
Remote Address: 192.168.xxx.xxx:80
Response headers
cache-control: no-store
content-length: 1535
content-security-policy: frame-ancestors 'none'
content-type: text/html
date: Fri, 01 Jul 2022 12:04:03 GMT
location: https://***/mga/sps/oidc/rp/***/kickoff/***?authLevel=2&autologon=true&TAM_OP=login
p3p: CP="NON CUR OTPi OUR NOR UNI"
pragma: no-cache
Set-Cookie: wap-***-session-cookie=***; Domain=***.int; Path=/; SameSite=None; Secure; HttpOnly
Set-Cookie: PD-S-SESSION-ID-wap-oidc-int=***:1_2_0_6gpve0u3mSK+***|; Domain=.***.int; Path=/; SameSite=None; Secure; HttpOnly
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1
This causes issues with our load balancer, as it hits a different endpoint.
Flow with working port 443
Often the flow will look like this with no issues:
Request URL: http://app1.test/
Request Method: GET
Status Code: 307 Internal Redirect
Referrer Policy: strict-origin-when-cross-origin
Response headers:
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://app1.test/
Non-Authoritative-Reason: HSTS
And the 2nd request:
Request URL: https://app1.test/
Request Method: GET
Status Code: 302 Moved Temporarily
Remote Address: 192.168.xxx.xxx:443
Referrer Policy: strict-origin-when-cross-origin
Response headers:
cache-control: no-store
content-length: 1535
content-security-policy: frame-ancestors 'none'
content-type: text/html
date: Fri, 01 Jul 2022 13:19:21 GMT
location: https://***/mga/sps/oidc/rp/***/kickoff/***?authLevel=2&autologon=true&TAM_OP=login
p3p: CP="NON CUR OTPi OUR NOR UNI"
pragma: no-cache
Set-Cookie: wap-***-session-cookie=***; Domain=***.int; Path=/; SameSite=None; Secure; HttpOnly
Set-Cookie: PD-S-SESSION-ID-wap-oidc-int=***; Domain=.***.int; Path=/; SameSite=None; Secure; HttpOnly
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1
Does someone know why the browser sometimes uses "Remote Address :80"?
Turns out it is in fact using port 443. I was looking at a HAR export from a colleague and there is a bug in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1334230
I'm having problems with JWT cookies set by Set-Cookie headers.
After correct credentials are sent, the backend returns these headers for a website website.com and path website.com#login and backend is on a different domain backend.com`:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://website.com
Allow: POST, OPTIONS
Connection: keep-alive
Content-Length: 678
Content-Type: application/json
Cross-Origin-Opener-Policy: same-origin
Date: Mon, 28 Feb 2022 14:39:55 GMT
Referrer-Policy: same-origin
Server: nginx/1.18.0 (Ubuntu)
Set-Cookie: jwt-access-token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjQ2MDYyxxxxxxxxxxxxxxxxxxxxxxxxx4MTE5YzQzM2JiYmE0MDFlMWNlYTNiZDM4IiwidXNlcl9pZCI6MTAwMDB9.ut8VUSKDHTi4zTOY5Gr0qlbWG7pYhxxfok_rE1Pju74; expires=Mon, 28 Feb 2022 15:39:55 GMT; Max-Age=3600; Path=/; SameSite=None; Secure
Set-Cookie: jwt-refresh-token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTY0ODY1xxxxxxxxxxxxxxxxxxxxxxxxxxxxdGkiOiI4YzJlZWFkZWIxMjI0MDBkYTYwNWJmMDkwMjM5ODhkNCIsInVzZXJfaWQiOjEwMDAwfQ.-CE1JvtXhoLksKfxIf2bM8u80U4Fcr83yaoEmqqs2SI; expires=Wed, 30 Mar 2022 14:39:55 GMT; Max-Age=2592000; Path=/; SameSite=None; Secure
Set-Cookie: csrftoken=mugKGWG8R4936Dxxxxxxxxxxxxxxxxxxxxxxxx9XElIy704ZuDau; expires=Mon, 27 Feb 2023 14:39:55 GMT; Max-Age=31449600; Path=/; SameSite=None; Secure
Set-Cookie: sessionid=1heuj9ui88xxxxxxxxxtrahr; expires=Mon, 14 Mar 2022 14:39:55 GMT; HttpOnly; Max-Age=1209600; Path=/; SameSite=None; Secure
Vary: Accept, Cookie, Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
You can see Set-Cookie headers but they are not set and sent with the next requests.
Do you know where is the problem? I've turned off "httpOnly" param but that didn't help.
I want to make sure that some of my responses will not be cached by anyone.
One of the advised options is to set Vary: *.
Unfortunately my nginx which has enabled gzip support returns me two Vary headers if i add add_header "Vary" "*";
HTTP/1.1 200 OK
Server: nginx/1.11.1
Date: Mon, 16 Jan 2017 14:56:16 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Vary: *
Any idea how to force having only Vary: * in responses and gzip support for the request on?
gzip_vary off;
should stop gzip from auto-adding Vary header.
docs: http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_vary
When I recently curled my company's website, some headers appear to be duplicated in both names and values. For example, this is the full response from curl:
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 19 Dec 2016 15:54:37 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 53272
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
X-Frame-Options: ALLOW-FROM https://policygenius1424796031.zendesk.com/
ETag: W/"2515e7e2b57063c8029ea978bf98b6e7"
Cache-Control: max-age=0, private, must-revalidate
Set-Cookie: analytics_id=OW53dllLeGVPZ1YzR21vOVRvU1V5WjRBeklGNHdXeERpNVNNM3ZLd2djcnpBUjlnTzRWblFIYitHM0VtdWUzei0tN284NTV3RUVrRm9nVkhpTm1NZU5qQT09--b43227e963c8680e5b2984c13483e65ae67c8b6a; path=/; expires=Wed, 18 Jan 2017 15:54:37 -0000
Set-Cookie: request_method=HEAD; path=/
Set-Cookie: _policy_genius_session=bUVTYW5KU2FzQTh2bG44WEdvcExWK2d4NzJtNUlOSnpqUWhzL2tVSkhFTUNuODFWVkhmYU9mWVUySlpDbmlkdCttbVpZOXV0NHVYY3VWbFphYlA2S0tOdmROSFVMNUJ1QWNMMFpMcm5DZGEyTkdqSTBMMnNoTi9mMmJ2L01lSlRuSGhmMk8ydXBOYVNNcXA1Z1crWXUvelpvSDlYdWFZYjYxc0p2MGdPYnhNNm1FSFpDSFpYSU9Jb3F2UFhMQTVoTm12cXQ4bEdNMkpaVy95cWVQK094RXkwVmo5ZlE0UXdoMzA3LzJiQllkMW9jZS9xZmpiMEI0ZHFVMTNQSHlBbi0tSE51NGZyeEx2Nk95c3NxNWtHbjNhUT09--d1107337bb68f2861ffc6f081012441bd7554501; path=/; HttpOnly
X-Request-Id: 4a812c77-719e-4163-a665-5059a2b1e3a6
X-Runtime: 0.133390
Vary: Origin
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
Notice Strict-Transport-Security and Vary are duplicates and have same values too. I am aware that it's ok to have duplicate header names with different values (here), but same values?
Second part of the question: is anyone aware of negative effects of such duplication?
When i login with gmail , i see this header ('x-auto-login') in one of the http repsonse, what is the purpose of it:
gtglobal-ocsp.geotrust.com
:Alternate-Protocol: 443:quic
Cache-Control: no-cache, no-store
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Thu, 06 Mar 2014 22:26:41 GMT
Expires: Mon, 01-Jan-1990 00:00:00 GMT
Pragma: no-cache
Server: GSE
Set-Cookie: GAPS=1:8823f898f8dsf8sd6g;Path=/;Expires=Sat, 05-Mar-2016 22:26:41 GMT;Secure;HttpOnly
GALX=axHR8TU45uo;Path=/;Secure
Strict-Transport-Security: max-age=10893354; includeSubDomains
x-auto-login: realm=com.google&args=service%3Dmail%26continue%3Dhttp%253A%252F%252Fmail.google.com%252Fmail%252F
x-content-type-options: nosniff
X-Frame-Options: DENY
x-xss-protection: 1; mode=block
X-Firefox-Spdy: 3.1
[Note: I have intentionally changed the cookie value for security reason]
The HTTP header x-auto-login allows to auto-login a user in Chrome.
See here for a code reference.
https://code.google.com/p/chromium/codesearch#chromium/src/components/auto_login_parser/auto_login_parser.cc&q=x-auto-login&sq=package:chromium&dr=C&l=42
So if you use Chrome or Chromium at a site the has the header then Chrome will redirect to Google's openid consent page. If you are loggedin at Google already the login to the new site is quite smooth.
There does not seem to be an official description of the header nor a W3C standard for it.