Varnish vcl_backend_response not called - varnish-4

I came across inconsistencies with Varnish 4.x documentation.
According to the documentation vcl_backend_response will be called each time an object is fetched from the backend and the backend doesn't return an error (and is alive and healthy).
However, I noticed many of the 'fetch' requests (resulting from misses) are not going through this function at all.
Here is an example output:
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 294915 fetch
- Timestamp Fetch: 1504198046.101306 0.003644 0.003644
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Server: nginx/1.10.3 (Ubuntu)
- RespHeader Date: Thu, 31 Aug 2017 16:47:26 GMT
- RespHeader Vary: Accept-Encoding
- RespHeader Last-Modified: Thu, 31 Aug 2017 16:42:58 GMT
- RespHeader Expires: Thu, 31 Aug 2017 16:47:26 GMT
- RespHeader Cache-Control: public, max-age=90, s-maxage=332
- RespHeader Pragma: cache
- RespHeader X-Lift-Version: 2.6.3
- RespHeader X-Frame-Options: SAMEORIGIN
- RespHeader Content-Encoding: gzip
- RespHeader Content-Type: application/json; charset=utf-8
- RespHeader X-Varnish: 294914
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish-v4
- VCL_call DELIVER
- RespHeader grace: none
- VCL_return deliver
as opposed to a flow that adheres the documentation:
- VCL_call BACKEND_FETCH
- VCL_return fetch
- BackendOpen 22 boot.default 127.0.0.1 9919 127.0.0.1 22536
- Timestamp Bereq: 1504198040.603601 0.000222 0.000222
- Timestamp Beresp: 1504198040.659723 0.056345 0.056123
- BerespProtocol HTTP/1.1
- BerespStatus 200
- BerespReason OK
- BerespHeader Server: nginx/1.10.3 (Ubuntu)
- BerespHeader Date: Thu, 31 Aug 2017 16:47:20 GMT
- BerespHeader Content-Type: text/html;charset=utf-8
- BerespHeader Transfer-Encoding: chunked
- BerespHeader Connection: keep-alive
- BerespHeader Vary: Accept-Encoding
- BerespHeader Last-Modified: Thu, 31 Aug 2017 16:42:58 GMT
- BerespHeader Expires: Thu, 31 Aug 2017 16:47:20 GMT
- BerespHeader Cache-Control: public, max-age=21600, s-maxage=21600
- BerespHeader Pragma: cache
- BerespHeader X-Lift-Version: 2.6.3
- BerespHeader X-Frame-Options: SAMEORIGIN
- BerespHeader Content-Encoding: gzip
- TTL RFC 21600 10 -1 1504198041 1504198041 1504198040 1504198040 21600
- VCL_call BACKEND_RESPONSE
So - according to Varnish log - when there is a miss and the object is fetched from the backed vcl_backend_response is not invoked.
Unless I'm missing something - this contradicts the documentation.

There are no inconsistencies in the documentation. What you see is the normal behaviour since Varnish 4.0. During a cache miss, you'll see (at least) two transactions in varnishlog: (1) the one handling the client request (usual flow is vcl_recv → vcl_hash → vcl_miss → vcl_deliver; i.e. the first log excerpt in your question); and (2) the one handling the request to the backend side (usual flow is vcl_backend_fetch → vcl_backend_response; i.e. the second log excerpt in your question). That's why you don't see references to vcl_backend_response in the client transaction.
Obviously both transactions are connected. At some point the client transaction creates and waits for completion of the backend transaction. That's shown in the log of the client transaction:
- ...
- Link bereq 294915 fetch
- ...
That means a backend transaction was created (VXID 294915) in order to fetch an object from the origin.

Related

connect DASHBOARD to NODE-RED

I have an external Freeboard Dashboard that I need to talk to a remote Node-Red server. Using the built in Node-Red-Dashboard is not an option.
I cannot get Freeboard to recognize the Node-Red server as a JSON source. I have made sure my Freeboard installation works by using http://ip.jsontest.com.
I have checked the header and output of the Node-Red server but still no luck.
Node-Red Header: http://10.0.3.3:1880/hello
http://ip.jsontest.com
HTTP/1.1 200 OK
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Type: application/json
Content-Length: 16
X-Cloud-Trace-Context: c4378d0107d5df3af2613...
ETag: W/"10-zPVCxAyElRj7W5BuknPouQ"
Content-Length: 23
Date: Mon, 17 May 2021 14:41:34 GMT
Date: Mon, 17 May 2021 14:43:02 GMT
Connection: keep-alive
Server: Google Frontend
Node-Red Page Source:
{"Signal" : "3"}
ip.jsontest.com Page Source:
{"ip": "99.140.82.10"}
Help.

Access-Control-Allow-Origin error in Chrome

Got this in Chrome dev console:
Font from origin 'http://cdnjs.cloudflare.com' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://xx.xx.xx.xx:8000' is therefore not allowed
access.
However, I did this:
curl -I http://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.2.0/fonts/fontawesome-webfont.ttf?v=4.2.0
HTTP/1.1 200 OK
Date: Thu, 11 Dec 2014 15:51:47 GMT
Content-Type: application/font-sfnt
Content-Length: 112160
Connection: keep-alive
Last-Modified: Thu, 28 Aug 2014 04:30:29 GMT
Expires: Tue, 01 Dec 2015 15:51:47 GMT
Cache-Control: public, max-age=30672000
Access-Control-Allow-Origin: *
So what's going on??
EDITED
Oh never mind, I resolved it by using https: instead of just // ..
I resolved it by using https: instead of just // ..

Google Groups Settings API failing with System Errors

Having had repeatedly no joy with accessing groups settings via UrlFetch in GoogleAppsScript I looked to test the basic query I was using according to the docs in the APIs Explorer
UrlFetchApp.fetch('https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?key={YOUR_API_KEY}', fetchArgs);
Never completes a round tring
The fact that the APIs explorer also fails with similar errors at least gives me some comfort, but where to report the failing?
GET https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?key={YOUR_API_KEY}
Authorization: Bearer ya29....[snip]
X-JavaScript-User-Agent: Google APIs Explorer
gives
200 OK
cache-control: private, max-age=0, must-revalidate, no-transform
content-encoding: gzip
content-length: 731
content-type: application/atom+xml; charset=UTF-8
date: Tue, 12 Nov 2013 11:31:09 GMT
etag: "N…[snip]…I"
expires: Tue, 12 Nov 2013 11:31:09 GMT
server: GSE
[application/atom+xml; charset=UTF-8 data]
adding any field to the query
GET https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?fields=archiveOnly&key={YOUR_API_KEY}
Authorization: Bearer ya29....[snip]
X-JavaScript-User-Agent: Google APIs Explorer
always results in error
400 Bad Request
cache-control: private, max-age=0
content-encoding: gzip
content-length: 209
content-type: application/vnd.google.gdata.error+xml; charset=UTF-8
date: Tue, 12 Nov 2013 11:33:34 GMT
expires: Tue, 12 Nov 2013 11:33:34 GMT
server: GSE
[application/vnd.google.gdata.error+xml; charset=UTF-8 data]
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="http://schemas.google.com/g/2005">
<error>
<domain>GData</domain>
<code>invalidParameter</code>
<location type="parameter">fields</location>
<internalReason>Invalid field selection archiveOnly</internalReason>
</error>
</errors>
Is the API borked?
Try using the Google OAuth 2.0 Playground instead. I think the Groups Settings API Explorer is broken.
I am also having trouble with implementing with in Apps Script. I am stuck in an authorization loop. Similar to this reported bug. https://code.google.com/p/google-apps-script-issues/issues/detail?id=3046

Why I'm not able to view the source of any js file in Google Chrome?

This one works:
view-source:http://code.jquery.com/jquery-2.0.3.min.js
This one does not:
view-source:http://pagead2.googlesyndication.com/pagead/show_ads.js
The network status is "canceled". Response headers:
HTTP/1.1 200 OK
P3P: policyref="http://www.googleadservices.com/pagead/p3p.xml", CP="NOI DEV PSA PSD IVA IVD OTP OUR OTR IND OTC"
Content-Type: text/javascript; charset=UTF-8
ETag: 18135184975683587730
Date: Thu, 11 Jul 2013 10:00:44 GMT
Expires: Thu, 11 Jul 2013 11:00:44 GMT
X-Content-Type-Options: nosniff
Content-Disposition: attachment
Content-Encoding: gzip
Server: cafe
Content-Length: 6489
X-XSS-Protection: 1; mode=block
Age: 2014
Cache-Control: public, max-age=3600
Without "view-source" I'm able to download the file and view the source but I want to know why this happens.
A strange thing in addition is, that it is not possible to open the web delevoper tools after opening this view-source url. If you do, the tools are completely blank:
I'm taking a guess here: it has to do with the Content-Disposition setting in the Response Header.
Reference: http://support.microsoft.com/kb/260519.

why do I see the source code (html) of some web pages?

Most web pages are normally parsed and of course I don't see tags like <html> or <a href=>.
But, when I open some web sites, the source code pops up.
Try this
http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
So I saved this web page and reopened locally using firefox, everything seems normal again.
any reasons?
You're viewing the file in an SVN repository browser. They must have the encoding for the documents in these directories set to render as plain text. I am using chrome and saw the same thing. It's by design in this case.
As everybody says, it is the server side (Apache) configuration. You can confirm this by issuing HEAD request.
curl -I http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
returns
HTTP/1.1 200 OK
Date: Thu, 29 Dec 2011 00:27:49 GMT
Server: Apache
Last-Modified: Thu, 16 Oct 2008 18:13:57 GMT
ETag: "2//jes/JESHelp/auxHelp/mediaToolsOverview.html"
Accept-Ranges: bytes
Expires: Thu, 29 Dec 2011 00:30:49 GMT
Content-Length: 1802
Content-Type: text/plain
Cache-Control: public, max-age=180
Age: 0
Notice that Content-Type says "text/plain"
You're looking at a svn repository, and the response type is text/plain instead of text/html, so the browser renders it as text instead of html
SVN or not the important for the browser is the header Content-Type - the most of the pages are rendered as html, no matter the extension or absence of such, because of the header. Another effect obviously will be that JavaScript won't be executed.
About the Content-Type ietf and MIME types list Wikipedia
Header Content-Type: text/html; charset=utf-8 - rendered
lynx -head -dump http://stackoverflow.com/questions/8662745/why-do-i-see-the-source-code-html-of-some-web-pages
HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Length: 41163
Content-Type: text/html; charset=utf-8
Expires: Thu, 29 Dec 2011 00:26:08 GMT
Last-Modified: Thu, 29 Dec 2011 00:25:08 GMT
Vary: *
Date: Thu, 29 Dec 2011 00:25:08 GMT
Connection: close
Header Content-Type: text/plain - displayed as text
lynx -head -dump http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
HTTP/1.0 200 OK
Date: Thu, 29 Dec 2011 00:26:00 GMT
Server: Apache
Last-Modified: Thu, 16 Oct 2008 18:13:57 GMT
ETag: "2//jes/JESHelp/auxHelp/mediaToolsOverview.html"
Accept-Ranges: bytes
Expires: Thu, 29 Dec 2011 00:29:00 GMT
Content-Length: 1802
Content-Type: text/plain
Cache-Control: public, max-age=180
Age: 0
This is because this page has been encoded and then put in the page. So if you look at the page source your see it is written like <html> <head> <title> obviously because some one wants to show the page mark up. Nothing wrong with your browser etc