I am test running Drupal 7 on a local Centos/LAMP VM, not connected to the Internet, with Varnish and the Varnish Module installed.
I can't tell if Varnish is working or not. As I cannot put my instance on the Internet, I cannot use http://www.isvarnishworking.com/ to test.
Chrome returns the following at http://localhost/data:
1st run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:22:12 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Etag: "1473268932-1"
Last-Modified: Wed, 07 Sep 2016 17:22:12 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Content-Length: 7579
Content-Type: text/html; charset=utf-8
X-Varnish: 162
Age: 0
Via: 1.1 varnish-v4
Connection: keep-alive
Accept-Ranges: bytes
2nd run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:23:01 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Etag: "1473268981-1"
Last-Modified: Wed, 07 Sep 2016 17:23:01 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Content-Length: 7583
Content-Type: text/html; charset=utf-8
X-Varnish: 917543
Age: 0
Via: 1.1 varnish-v4
Connection: keep-alive
Accept-Ranges: bytes
curl -Ij http://localhost/data returns the following:
1st run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:25:27 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Last-Modified: Wed, 07 Sep 2016 17:25:27 GMT
Vary: Cookie,Accept-Encoding
Content-Type: text/html; charset=utf-8
X-Varnish: 786539
Age: 0
Via: 1.1 varnish-v4
ETag: W/"1473269127-1"
Connection: keep-alive
2nd run:
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 17:25:27 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=60
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
X-Generator: Drupal 7 (http://drupal.org)
Last-Modified: Wed, 07 Sep 2016 17:25:27 GMT
Vary: Cookie,Accept-Encoding
Content-Type: text/html; charset=utf-8
X-Varnish: 917560 786540
Age: 26
Via: 1.1 varnish-v4
ETag: W/"1473269127-1"
Connection: keep-alive
Here is part of my /etc/varnish/default.vcl:
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "8080";
}
Here is part of my /etc/httpd/httpd.conf:
Listen 8080
NameVirtualHost *:8080
Finally, here are my admin/config/development/performance settings:
CACHING
Cache pages for anonymous users (checked)
Cache blocks (checked)
Minimum cache lifetime: none
Expiration of cached pages: 1 min
It seems like Varnish is working for curl but not for Chrome. From what I have read about Varnish under Drupal, I should be seeing a two values for X-Varnish, which I see on my second curl run but do not see in Chrome. I don't know if I should see Drupal cache as a HIT because doesn't Varnish provide the cache? Not seeing anything that says HIT for Varnish, however.
Any help would be great.
Thanks
In response to Ronald's question, here are the Chrome Request Headers:
GET /data HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: has_js=1
If-None-Match: "1473274273-1"
Related
I’m working on a website which is deployed kén azure and login through azure microsoft. However, it only works on login website on computer. Whenever I login to the website by some account ( on an ipad or an iphone, it turns to signin-oidc (error 500) and then I cannot access to home page or the other pages . Anybody face to this problem and is there any solution for this? Thanks
Go to my website -> login -> azure microsoft login page open -> login by azure microsoft -> return token from azure microsoft to client -> my website check access this token -> ....
Here is the content of the BeginAuth:
Summary
URL: https://login.microsoftonline.com/common/SAS/BeginAuth
Status: 200 OK
Source: Network
Address: *******
Initiator:
AjaxHandlerControl.js:110
Request
POST /common/SAS/BeginAuth HTTP/1.1
Content-Type: application/json; charset=UTF-8
Accept: application/json
Accept-Language: vi-vn
Accept-Encoding: br, gzip, deflate
Origin: https://login.microsoftonline.com
User-Agent: Mozilla/5.0 (iPad; CPU OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Referer: https://login.microsoftonline.com/
Content-Length: 2220
Connection: keep-alive
Cookie: ESTSAUTH=AQABAAQAAABeAFzDwllzTYGDLh_qYbH8o3IjKkzc2x1r88yy-081xaEhysFzWkgE5Giluas3rg_Dp5-Fw5bh9r4-LSLhpkG14oOyEzrVVAOR4NPQXDA5JIAKdw1Xtan0t4znDHFGqQVix1O2lkm-Y2o1nlDxmM-_swpy5MAxb7yb_b2tA_b2ZMT_MoLndRqejWKdawyYST7h5bMr6ewZNg2ts52SqlXt4BveNWIWrq5mN-xO0D4_SyqC6DPun5N_4wZoyI0I7Zj5qE9qsosdLlqgBiPi_O18QoWqRWhfjJ2B6LoteSlSaF9QgRP409lFoKBDcs5eLguK1uPGPd4X-2AXixn217QIFztBBs-EQzqiJly5xXykGURHG_PUzSaCA2akgGKyD-5QDEIKA8VCniiFHwqoX8EQGdXCUeDjC5AkBk1rxhfeAM06bJ0H-Uz6KWvV5mFNhxwmUwArKSR-QBaN5soW7k63SvO8eF31GP_u2MC4QXjZnXD8YeHclcp3qt4nHGrMJ204p85hj_Lnqj5Aio23f_4WGGJoOUN5RQIrWFP2ua81ww2Cz12xSBGPmSka7F5EeB8LNF_oYx2omVhhFVKZJapnyiuEap_DOyiEntQCsIy6SY8nNyDdkDhYAmjzSS0-uJPYkpO4JCUWq5Z8FN6wrne1hgdN5f-HaHCHPqJw1b73LxWPJMMlOb1TceHvDfDahII99BFhLcGAEZJYE28o2rBopNHNDqOz1PcryTdV4IgNmtYZwq_VtGBKUN60BRuxXbBCfXKb62j9tc4HD2fEfJ7dXLv15Zt-o9hFFeJCKc04419BG9r_yeZ0yMezJv7_8jea-JG3mjyPkVbwEfoD8nSkIAAgAEAA8AEAAA; ESTSAUTHPERSISTENT=AQABAAQAAABeAFzDwllzTYGDLh_qYbH896tJrsebgq-fyKSmZvVkIpkuag5kO86qDT_eS2hkuIxJ6npcaoiZ9um5ixOHEjDUiO6wxp5f4fWs81K6-A0RVQmVmcDA9h9G-QdBz0Hwk06y7stWRwp3SfhkmEuKdYxDhuyE7pImTl_n3Wsn3Ur3196goptzdQt7dRP9Mnplc9UH5D1yPwH5AHsN0MySAO281n3E9sdk0muJOM7cD2IKRGSnSki5wV-Tt3hCSh9WiW-pkBDXn-3T0mY33ZfAOahd_rN7nkqLNmrNIHSmTEXSd-W7WO7Hbnc5Om5-_C16FD2Y8a52xTYPt11zxp4_LNw8IHxUhsRjnCz-vGGR0rYdqN9NGvYTxxKYtXX2Ws4gs8K1yDxYIAA5GvKbqikiDdeGby75flRayIzUIfbv0N86AAhpTzI1Vr2fH1Q6_16r_g9z25A8mjTI73rr6ZxBoSLxHrw3ZnFa-tJ-meYxbJyXXZYn3AALE27UVQfM8y3EC-4kcaG7jdN0m_KTv5_aEA_ih9KBYPWe8bznfYRsGpj8lOVJRqY-YfpRBauFUsjS0dvec4JrImQM3ZRXbTuEedz5OQsAwqc5tPTI4qjcQRFwKCAAIABAAEABAAA; ch=eOAhIE0-NkRYjR4kYgO1gT7y31dmx3VL9YMxYR9WdoI; ESTSAUTHLIGHT=+cf40cdde-d9b9-4c8a-a402-a73a4ec99c66; ESTSSC=00; buid=AQABAAEAAABeAFzDwllzTYGDLh_qYbH84TKiKjYi6BuVyBpssR3qZD2fNIWjWH4IUGj1tgV1CjBekKsQGEtqYNmdMRIXd7N8BOo9vpLQC07NWlPoRa1jUH_-ayS6xTMT9xGQjDEZ1UggAA; fpc=Ah-RTB1jgiFCgCfEhHxEiA42YPZ6AgAAABNet9UOAAAAElWPKAEAAABFXrfVDgAAAA; stsservicecookie=ests; x-ms-gateway-slice=prod; clrc={%2218281%22%3a[%22MGmgPvDz%22%2c%22k+8Er6ui%22]}; brcap=1; esctx=AQABAAAAAABeAFzDwllzTYGDLh_qYbH8LpxpIlSUEu2HI0fzE_V_IRZe2RNJp-f2QqQ5Q3Ier3lWomWnATFbyAXP5tkq-U9ruARvMs7F-zosSlydkgEpjXJzyEyfRACjhZ_vKuEVUEqzKoCErpAbskdeRUTjqrMo70cB4tpzTB4GZFZonBLCTk0Ml3cUT-LLTZuhiu3Y_h4gAA
Host: login.microsoftonline.com
hpgact: 2101
canary: AQABAAAAAABeAFzDwllzTYGDLh_qYbH8a9SO3xGF3g6AWJIZDi54fWSNEiKErEt6YvrvJ3Fm-lIO4Y7kO9-ACPx-kAIHTbn_u5mhreKAsiP-Hn_b2PV7QPvjMYjHNFmOtYhXtFueCuvsxD-V2agrgXRBl82z91-Vv7ketwmG5XCIAJ4RBJBnEHiv2jAc671jIueFntKCDdwcbJ2t-karKLeSSx7VYafv5aDr8MhFDm-03Io8LpfLVSAA
hpgid: 1114
hpgrequestid: aa519c8c-30f9-46dd-95bb-ee6094414d00
client-request-id: 8fa2950c-7b79-400d-ac8c-630c65ec4c48
Response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Pragma: no-cache
Set-Cookie: fpc=Ah-RTB1jgiFCgCfEhHxEiA42YPZ6AgAAABNet9UOAAAAElWPKAEAAABFXrfVDgAAAA; expires=Wed, 19-Feb-2020 08:39:37 GMT; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=prod; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly; SameSite=None
Expires: -1
Cache-Control: no-cache, no-store
Date: Mon, 20 Jan 2020 08:39:36 GMT
Content-Length: 2356
X-Content-Type-Options: nosniff
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
x-ms-ests-server: 2.1.9898.20 - SIN1 ProdSlices
x-ms-request-id: 0c407fdc-ec18-4822-9d91-d3c662525100
Strict-Transport-Security: max-age=31536000; includeSubDomains
client-request-id: 8fa2950c-7b79-400d-ac8c-630c65ec4c48
Request Data
MIME Type: application/json
Encoding: UTF-8
Request Data:
Here is the content of the EndAuth:
Summary
URL: https://login.microsoftonline.com/common/SAS/EndAuth
Status: 200 OK
Source: Network
Address: *****
Initiator:
AjaxHandlerControl.js:110
Request
POST /common/SAS/EndAuth HTTP/1.1
Content-Type: application/json; charset=UTF-8
Accept: application/json
Accept-Language: vi-vn
Accept-Encoding: br, gzip, deflate
Origin: https://login.microsoftonline.com
User-Agent: Mozilla/5.0 (iPad; CPU OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Referer: https://login.microsoftonline.com/
Content-Length: 2249
Connection: keep-alive
Cookie: clrc={%2218281%22%3a[%22k+8Er6ui%22%2c%22MGmgPvDz%22%2c%22zHWAEBZj%22]}; fpc=AqGp0xmfg8lLgos3zMYZv1E2YPZ6AQAAAD9nt9UOAAAAElWPKAEAAABzZ7fVDgAAAA; stsservicecookie=ests; x-ms-gateway-slice=prod; ESTSAUTH=AQABAAQAAABeAFzDwllzTYGDLh_qYbH8PFcC4jCAPANOfMbq-YWj9-5u5ZM2Hz4lOtVb4th1FHqBtfAlPxYXbkTjGWbI0eqbYK3yBdWUzJaf_pjfuAqipUpJKfo388tRwdsTr9CtHJCsb2Bb-gj7weggZrS9qDlSiQ5yPiNdbpi1Q3eeed7T6rOIPDkM2JzgwuQPRTy1A7OElUbdPfqV1-y03NT-Oad5niK4qIyLO3qbUiXXSWAHPvW4Qucn9u5all3U2DEgJN5oDLwy58GOvgcl3m1N6XtwA8Ty67IybRFIWQD86VrNJwoTV9PD6mXBm7LI0ITaa9a6_3V2jBkVTIgVK8BTQUPdQs5SDFD_M9ER8mLbd99HRVlw_aB0rPB_wyML3EDDtStBbbm2PpLF7-Bc9LHmNdXhVTrtUlob46GTiSput6771BBKXJ1O7fVHv85aLIHoCq31FQwDxO8CxoRa-RK1AECnEVckc8FXVUzOEpr4AzIlB85f82AyKGX0TwmssksASFUd7gCiRNVVRQCgmORCqZgW-juZjLKFBPMbS9DnavYyxTmhzNKkHSy-9cIXFfEpCXlUXyYVJSoLBvKpFY9yWaz6-G1G86YiuLIjYzJQTHv0tgq403dHQ49M10FiOPpgrtVuUQu6Vg-4UIaZ-qy8RWEFrB13CFkhalyGgFdZfVEuzUaKM1WQAQaYa0w15Zvt2rtBSJWe9lD9RN4VGDOm2fUT_h_JAUBc5IqMMurH2ZtAL5ntKaQLM7cUytZ7dzt6OPJCK1UGRfI-bRIBtnjkSD0sKeScwrGzY9kLqjYc7YiiEjx-7z3yEn5x3pCwjQUMv__dDdCA-Q8gHFtrcBQcwLaOIAAgAEAA8AEAAA; ESTSAUTHPERSISTENT=AQABAAQAAABeAFzDwllzTYGDLh_qYbH8xJRdtnbkjGoFDDkcczRP-0vt8McGva1mrQ4Hlj-urVvuUAnk3WtFW0VM9UaZC0uE3AHrqYFjQ49FnfueYD8s2uwtC89QXtud4HyBPZx7VFdcTf4nbjQqWl--UfStURhk7Jkr-hiCQo8stX1jy5xTKD91nYnkt4Jh_lhO4ul5ByQcYAiH1aWvE-2FCt1bKOxs1-DnYPhvvl9sa0s6C4Awpz7kzLn0o_FlUeVNDoQ7AU99IU6gKeetRRx8MTFUy5enxbviahbL97gIoV3FX5MuVd40d_9QCwXD2QB450NgGPRAhyM81l0bHT7anMjcDhl-7fj26i2q6EGm0LTQvRH3C3BdpJrafvkBKZaDOqdpoqgQWefiS4JAPtDRJlKCoraFryHLRKuKIwSwT_0-q0B2Wbz2eA0-uVeQoT9QRycHAIi4uWMbpSlQIoOh8uDQ4XWkKxC1qIPGH5ph6yZGr6DBs9zw8F52_ABHjQtjZeqLwOH_2tJwhHlhRjseQQ-sfPqs2unGfEqH_ea1HcT6ghJkMwKbyWw5FgO_HtElrYNn9BIQt04jPBBupWH57uw-GdKlnyk1_iUFhTIG8In4g6nfoyAAIABAAEABAAA; ch=2ZexXvpi5pBsPVR3WldndSN3Jss01W9lqt3Oo4atPto; ESTSAUTHLIGHT=+ccbda084-3cfd-4fba-a121-64822022264b; ESTSSC=00; buid=AQABAAEAAABeAFzDwllzTYGDLh_qYbH83h0-hsSMC7dM5dkdMfsldYZQhtZ_5IMn2ZWccmkXmkyQugUDrd1sqLyFIo52qI1ICYVz0_3ozkcTDV1vemApeSunFPxJEyWbLhKWIIMiRSwgAA; brcap=1; esctx=AQABAAAAAABeAFzDwllzTYGDLh_qYbH8C_SETJvY2bJWBn6b4YBwYZ7oWTYtAHOB03Kf6w7z6vx4agejzLR-KrengZwkpZuVxa46rpVJHyjKDFiK21Ze093B5qYDaOrkz3uZPgiJdYqVbjuCum0RxKS6CmtEx7u5UHUmbF28DhO-fw7SE8GiQOgk-WMKtZ5l15V323DZ2yAgAA
Host: login.microsoftonline.com
hpgact: 2101
canary: AQABAAAAAABeAFzDwllzTYGDLh_qYbH8B01oIe03wUWEzPISTHAYY9DIzppZsJdHlAJVTT_qDkwW63QTbVzZyGyuWTH8DI13YW7IQFYQyNSmc82iyDqXYnIYXKzNwTXHaKFvgefiHsMs4s_H-iKu7nbw5riTkXpshEv8RqrNzUCQ5RzPkN_DmRrl6pxzpx5PE9xy_lbhsMNJhlRHR9ydR32alGrgIUMk5jeiWnXwyn-Iv0ZeaTm_liAA
hpgid: 1114
hpgrequestid: 6046baec-30dd-4d4d-b4c0-c2a9bdd65000
client-request-id: 907865da-9681-4d95-a65a-dd40a3661f79
Response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Pragma: no-cache
Set-Cookie: fpc=AqGp0xmfg8lLgos3zMYZv1E2YPZ6AQAAAD9nt9UOAAAAElWPKAEAAABzZ7fVDgAAAA; expires=Wed, 19-Feb-2020 09:19:24 GMT; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=prod; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly; SameSite=None
Expires: -1
Cache-Control: no-cache, no-store
Date: Mon, 20 Jan 2020 09:19:23 GMT
Content-Length: 2356
X-Content-Type-Options: nosniff
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
x-ms-ests-server: 2.1.9898.20 - SIN1 ProdSlices
x-ms-request-id: be26f84b-5386-4b04-a31f-64f06db04e00
Strict-Transport-Security: max-age=31536000; includeSubDomains
client-request-id: 907865da-9681-4d95-a65a-dd40a3661f79
Request Data
MIME Type: application/json
Encoding: UTF-8
Request Data:
Here is the content of the failed signin-oidc content:
Summary
URL: https://*****/signin-oidc
Status: 500 Internal Server Error
Source: Network
Address: *****
Request
POST /signin-oidc HTTP/1.1
Cookie: ARRAffinity=b67cf4989142f516cf1224c1da63f82fb954c6d5a9d7f17d287740c0647a1f76
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/x-www-form-urlencoded
Origin: https://login.microsoftonline.com
Content-Length: 1886
Accept-Language: vi-vn
Host: *******
User-Agent: Mozilla/5.0 (iPad; CPU OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Referer: https://login.microsoftonline.com/kmsi
Accept-Encoding: br, gzip, deflate
Connection: keep-alive
Response
HTTP/1.1 500 Internal Server Error
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Date: Mon, 20 Jan 2020 08:23:38 GMT
Transfer-Encoding: Identity
Cache-Control: no-cache
Access-Control-Allow-Origin: *
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=2592000
Server: Kestrel
Request Data
MIME Type: application/x-www-form-urlencoded
id_token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InBpVmxsb1FEU01LeGgxbTJ5Z3FHU1ZkZ0ZwQSJ9.eyJhdWQiOiJjNjA4ZjhhYi1lZjA4LTRjYjEtYjAzMy1hNzQyMjg0ODA3NmEiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vMWZkMWRmYzQtZTVlMy00ZDM3LWFkZGItM2VjYTQxMWVjYWVjL3YyLjAiLCJpYXQiOjE1Nzk1MDgyOTMsIm5iZiI6MTU3OTUwODI5MywiZXhwIjoxNTc5NTEyMTkzLCJhaW8iOiJBV1FBbS84T0FBQUFSUWhkYzc3SWNXN2dMb0RHcUVkN2pnV3hoRDdtK29Kb0NPS3A0SkRnS3VlL3JCdno2V2NYNysvOUlYYXREWURKeUp6Y0I5MWs5SjJIbVJSZ2tUVEsyNGdWM0dLS3hteXVBTnJGUk4waDJIdS9jYVN6K1FzNUc3R21kYXJSVG5jSCIsIm5hbWUiOiJOZ29jLCBMdXUgVGhpIFBodW9uZyAoU0FMRSkiLCJub25jZSI6IjYzNzE1MTA1MzMyNTE2MTI4OC5OVGRsTkdFMU1ESXRNRGRpWWkwME1tRTVMV0ppWTJZdE1URXlaak15WW1FNU5UYzVObU16WkdJM01tSXRObU5tT1MwME5qVmlMVGd4TVRndFpqY3dOMlUxT0dJNU9EVTUiLCJvaWQiOiJkZWJlNTRlNy0wOWE0LTQ2MDItYmFlZC1jNWRjN2VkM2NiMjMiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJuZ29jLmx1dXRoaXBodW9uZ0Bub3ZhbGFuZC5jb20udm4iLCJzdWIiOiJEV1E1Y0pEbVA3WHI2Szloakx1enNiS2RmUUs3cERWNzBYbmpYTkVmbzRjIiwidGlkIjoiMWZkMWRmYzQtZTVlMy00ZDM3LWFkZGItM2VjYTQxMWVjYWVjIiwidXRpIjoiMHdQNEIyUWhpa081WEJHYkxoRkxBQSIsInZlciI6IjIuMCJ9.MO2h7kO8I9ANFI9TgJZCVGpl0J7oxmeMQPMKM1Vt8AzXqLxN46CS1q4QlAR8x8Ca_D8IPpB277HpumUVc4vseffBJ9i_M_6I4Qqt2bzmHCcIRqTGluc8C-UlEBFvIBshOILCjVpS6feESboRTbWkIgVPfArlb03FtvS1HDinaWpAWRMPSNr40sYvF_3I7VT4wk52Ne1ZZRIhB71wAbeYzlcBlXQJA8yZhg2oGuoBy3B0V45v8f9Kskd7wIgvq0rI-kxSTKIo7pxHclNnvjDJm4J4DeAdA5dzKdmaCTzN4EMDsOZY0y1vM3UdJnM1BQkHip3FyRQ1Hj6eolbPwafdaQ
state: CfDJ8H2WPQdBhutNkjRYYA9J-dr_EWgqMxJ32ez0tMZ1rrPWWnow1tT8M7sqGJspDcOU08NK2Hhg12jGCXAuI8biXhycBguS-EZgJnh2pYPq7SE8Fin-XaF17rJDxNXCEp-B1Rw8sTVbNLo-cdaTf0tqKE01Ey2srTrQA3-5Y5EgsQnZ-PuhzykvglYxeBbV09e2wZ7Cw0AngaZBwTYrs-3ETv8sakZwXTX2gFjUy5q61MCxpdhHepRvd2lT7ZEAWNXGrzBBVoM-VM0C-Lztf65ZqNhP_0U8vgwHsxvzA47KWEGbdMLC80xoGNLO1p8zU3n9Yzkdp0fsc5z7ExBTVAexe6WBoALObVNPSWBOhR0BEdRFgkyPfWJBYBbQTqwv-C6CwBojTOI4e4GPGZfmJXvlKQg
session_state: 7f9db494-e7d2-4803-b8ec-979d0dad856f
Return this page and can't go anything page on my website
I am getting Unknown error (HTTP Code: 500) intermittently. Also, there is no exception log in Google Developer Console. Kindly help me to resolve this.
Note: My App engine's Endpoint don't have any authentication and it is open to hit.
Following is that intermittent response:
500 OK
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-encoding: gzip
content-length: 33
content-type: text/html; charset=UTF-8
date: Fri, 11 Sep 2015 13:30:18 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: GSE
Unknown Error
Although this question should be trivial, I didn't success to enable browser caching on web google app engine java server.
I've try to put this kind of thing in my appengine-web.xml:
<static-files>
<include path="/**.cache.**" expiration="365d" />
...
but when I'm looking the response header I find this in local:
Content-Length: 196084
Cache-Control: public, max-age=31536000
Expires: Fri, 10 Jan 2014 19:40:45 GMT
Content-Type: image/png
Last-Modified: Tue, 18 Dec 2012 21:41:22 GMT
Server: Jetty(6.1.x)
Which is fine... but this in production environment:
HTTP/1.1 304 Not Modified
ETag: "RV4Bpg"
X-AppEngine-Estimated-CPM-US-Dollars: $0.000000
X-AppEngine-Resource-Usage: ms=109 cpu_ms=0
Date: Thu, 10 Jan 2013 19:41:20 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Server: Google Frontend
Which is definitively not what I want :(
Any idea ? something I've missed ?
[EDIT]
for not yet downloaded content, my browser receive the following header:
HTTP/1.1 200 OK
ETag: "RV4Bpg"
Date: Fri, 11 Jan 2013 12:50:50 GMT
Expires: Sat, 11 Jan 2014 12:50:50 GMT
Cache-Control: public, max-age=31536000
X-AppEngine-Estimated-CPM-US-Dollars: $0.000000
X-AppEngine-Resource-Usage: ms=3 cpu_ms=0
Date: Fri, 11 Jan 2013 12:50:50 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Content-Type: image/png
Server: Google Frontend
Content-Length: 196084
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
X-RBT-Optimized-By: eu-dcc-sh02 (RiOS 6.5.5b) SC
An ETag and several contradictory 'Expires' and 'Cache-Control' ...
Is there several way to configure caching policy ? Could it come from my ISP ? or a proxy ?
When you are logged in to a Google App Engine application as an administrator:
The X-AppEngine-* headers shown in your question are included.
The Cache-Control: no-cache, must-revalidate header is included, because the X-AppEngine-* headers are private and must not be cached.
This is hidden at the end of the Responses section at https://developers.google.com/appengine/docs/python/runtime#Responses, which says that:
Responses with resource usage statistics will be made uncacheable.
Yes, Cache-Control is off because reply is HTTP 304.
The problem is that your browser saved the ETag: http://en.wikipedia.org/wiki/HTTP_ETag
Now for every request for the same url/content, browser provides ETag and GAE replies with HTTP 304 Not Modified.
Try changing the resource (image) at this url, checking another url that you have not yet loaded in this browser or using another browser or computer altogether.
Also, this is relevant: What takes precedence: the ETag or Last-Modified HTTP header?
I am debugging js code on localhost and I need to prevent the caching of files by the browser. I can't use a timestamp appended to the url because it erases chrome debugger breakpoints.
Usually I don't have to refresh the cache, but everyone in a while I do. It is a large problem because I go searching elsewhere for the bugs. I added this code to apache some time ago:
<IfModule mod_headers.c>
Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
</IfModule>
Can someone explain why Apache would mistake a file for valid or provide some additions to the configuration code that could fix this once and for all?
Headers using the solution below:
<IfModule mod_expires.c>
expiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType text/javascript "access plus 1 seconds"
ExpiresByType application/x-javascript "access plus 1 seconds"
</IfModule>
http://localhost/static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png
GET /static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/static/images/
Cache-Control: max-age=0
HTTP/1.1 200 OK
Date: Sun, 23 Dec 2012 19:33:20 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Thu, 28 Jun 2012 17:32:51 GMT
Etag: "b3c27-f1f-4c38bb88d96c0"
Accept-Ranges: bytes
Content-Length: 3871
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: image/png
HTTP/1.1 200 OK
Date: Sun, 23 Dec 2012 19:33:54 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Thu, 28 Jun 2012 17:32:51 GMT
Etag: "b3c27-f1f-4c38bb88d96c0"
Accept-Ranges: bytes
Content-Length: 3871
Cache-Control: max-age=1
Expires: Sun, 23 Dec 2012 19:33:55 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/png
The second request:
http://localhost/static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png
GET /static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/static/images/
If-Modified-Since: Thu, 28 Jun 2012 17:32:51 GMT
If-None-Match: "b3c27-f1f-4c38bb88d96c0"
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Sun, 23 Dec 2012 19:34:58 GMT
Server: Apache/2.2.22 (Ubuntu)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=99
Etag: "b3c27-f1f-4c38bb88d96c0"
Expires: Sun, 23 Dec 2012 19:34:59 GMT
Cache-Control: max-age=1
When delivering static files, Apache sends an ETag header, which is something like a checksum of the file. The browser will cache the file and remember the ETag, which is sent with the next request.
If the file changes the browser ETag should differ and the webserver should resend, when the etag is equal, the webserver will respond with 304 Not Modified. The ETag mechanism has a higher priority than other cache headers.
To disable etags you can use apaches
FileETag None
http://httpd.apache.org/docs/current/en/mod/core.html#fileetag
Wikipedia has a nice article about the Etag header
http://en.wikipedia.org/wiki/HTTP_ETag
Edit
This should be a waterproof configuration
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>
Don't forget that configuration changes require a server restart to take effect.
sudo /etc/init.d/httpd restart
EDIT2
Wrap filesMatch around the configuration to disable caching for specific file extensions only
<filesMatch ".(php|js|css)$">
FileETag None
[..]
</filesMatch>
If i understand your requirement correctly you want the web browser to not remember anything about the webpage you are accessing and your apache web server should treat it like a fresh page request. You may first want to enable mod_expires and mod_headers , i use ubuntu so mine was
a2enmod headers && a2enmod expires && service apache2 restart
than you want to add below code to do minimum cache-control,
<IfModule mod_expires.c>
expiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType text/javascript "access plus 1 seconds"
ExpiresByType application/x-javascript "access plus 1 seconds"
</IfModule>
If you are using firefox you can test this by installing/running Live Http header Plugin or if you are linux/unix you can run this request with curl -v your_url
I'm having problems getting SharePoint 2010/IIS 7.5 to respect byte-range requests. I'm developing a SharePoint 2010 Web Part using Silverlight, and am trying to retrieve part of a document stored inside SharePoint.
When I request a byte range of a file in SharePoint, the server responds with the entire file. However, if I request the same byte range from a file sitting on an Apache server, everything works as expected. Below are the http headers observed with Fiddler.
Any help would be really appreciated! Thanks.
Sent:
GET http://example.com/file.abc HTTP/1.1
Accept: */*
Accept-Language: en-US
Referer: http://example.com/index.html
Accept-Encoding: identity
Range: bytes=1061285-1064594
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4
Host: example.com
Connection: Keep-Alive
SharePoint also takes login credentials:
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Received from Apache:
HTTP/1.1 206 Partial Content
Date: Wed, 25 Aug 2010 22:40:34 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 20 Aug 2010 23:27:18 GMT
ETag: "b68e346-103ea9-a3c20180"
Accept-Ranges: bytes
Content-Length: 3310
Vary: User-Agent
Content-Range: bytes 1061285-1064594/1064617
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: application/x-zip
Received from SharePoint 2010 / IIS 7.5
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Content-Length: 1064617
Content-Type: application/octet-stream
Expires: Tue, 10 Aug 2010 22:40:56 GMT
Last-Modified: Wed, 25 Aug 2010 19:28:39 GMT
ETag: "{5A1DF927-D8CD-4BC0-9590-8188CF777A3D},1"
Server: Microsoft-IIS/7.5
SPRequestGuid: 99799011-5bdc-489f-99fd-d060a56d3ae4
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
X-SharePointHealthScore: 5
ResourceTag: rt:5A1DF927-D8CD-4BC0-9590-8188CF777A3D#00000000001
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename=file.abc
X-Download-Options: noopen
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.4762
Date: Wed, 25 Aug 2010 22:40:56 GMT
The problem is that SharePoint caching is off be default, and needs to be turned on to enable byte-range requests. See Disk-Based Caching for Binary Large Objects.
Note http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2:
"A server MAY ignore the Range header."
Thus whenever you are using a Range header you must be able to handle a 200 response. The fact that your server doesn't appear to support range serving is unfortunate, but conformant.