Why doesn't chrome cache google app engine blobstore - google-app-engine

I'm using blobstore to serve audio files embedded in HTML5 audio element. Because I have a blobkey as a part of url I can assume that for any given url its content will never change. That looks like a perfect setup for caching.
Yesterday I implemented a solution which seemed to work. At least I remember that it worked ;). Unfortunately today I discovered, that it doesn't work with Chrome and production server. It works perfectly with Internet Explorer and Firefox. It even works with Chrome and development server - I use version 1.7.6. My solution uses Cache-Control headers, but it seems that only Firefox makes any use of it. Additionally I added an ETag header. When I discover If-None-Match request header with the same value I return 304 code. That seems to work with Internet Explorer. It also works with Chrome and development server. I remember that it had worked yesterday with Chrome and production, but I'm not completely sure. Anyway the problem I have is why both caching mechanisms are ignored by Chrome. I suspect that it may have something to do with chunked encoding which is generated only for chrome, but I don't understand why caching is disabled in that case
And now a lot of details.
Firefox
Initial request headers:
Host: eduzabawy.appspot.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Range: bytes=0-
Referer: http://eduzabawy.appspot.com/dziecko/
Cookie: children="jEDor1B8VRDRJreWmUVlUQ\075\075"; session=eyJfc2lkIjoiWk91QmlsOEJlTEd4QVFuYVFiYkpsTyJ9|1365190508|81d81772f6f409dd57ad43a9f447f92d1b56d29e
Connection: keep-alive
Initial response headers:
HTTP/1.1 206 Partial Content
Cache-Control: public max-age=100000000
Content-Range: bytes 0-37249/37250
Content-Type: audio/ogg
Date: Fri, 05 Apr 2013 19:45:47 GMT
Etag: blobstore
Server: Google Frontend
X-Firefox-Spdy: 3
On subsequent loads it seems that Firefox doesn't even try to fetch the files. This is how I thought it should work.
Internet Explorer
Initial request headers:
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Host: eduzabawy.appspot.com
Connection: Keep-Alive
Cookie: children="WyzUQwHEzwX6qnjfn21KEw\075\075"; session=eyJfc2lkIjoia2VOd0llR0hvRHU1cUN0cE1QSWRpWCJ9|1365192921|f2279f82b21947c4d064dbf44a5ce9e1bd95cc0d
Initial response headers:
HTTP/1.1 200 OK
Cache-Control: public max-age=100000000
ETag: blobstore
Content-Type: audio/mpeg
Date: Fri, 05 Apr 2013 20:15:23 GMT
Server: Google Frontend
Content-Length: 4637
Subsequent request headers:
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Host: eduzabawy.appspot.com
If-None-Match: blobstore
Connection: Keep-Alive
Cookie: children="WyzUQwHEzwX6qnjfn21KEw\075\075"; session=eyJfc2lkIjoia2VOd0llR0hvRHU1cUN0cE1QSWRpWCJ9|1365192921|f2279f82b21947c4d064dbf44a5ce9e1bd95cc0d
Subsequent response headers:
HTTP/1.1 304 Not Modified
ETag: blobstore
Content-Type: audio/mpeg
Content-Length: 4637
Chrome + development server
Initial request headers:
Host: localhost:8080
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://localhost:8080/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="xYNsqzfdtZ-2Z764lFSzk1Ed8-g1QoNlcaexsD79gSY\075"; session=eyJfc2lkIjoiTE9CZDc0SHJENHF4OWJua1J4S3dTQSJ9|1365192253|37815772acab0bf44a0c501ea0fd0dc7c617dd09
Range: bytes=0-
Initial response headers:
HTTP/1.1 206 Partial Content
etag: blobstore
cache-control: public max-age=100000000
content-type: audio/mpeg
Content-Range: bytes 0-4636/4637
Content-Length: 4637
Server: Development/2.0
Date: Fri, 05 Apr 2013 20:32:19 GMT
Subsequent request headers:
Host: localhost:8080
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://localhost:8080/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="xYNsqzfdtZ-2Z764lFSzk1Ed8-g1QoNlcaexsD79gSY\075"; session=eyJfc2lkIjoiTE9CZDc0SHJENHF4OWJua1J4S3dTQSJ9|1365192253|37815772acab0bf44a0c501ea0fd0dc7c617dd09
Range: bytes=0-4636
If-None-Match: blobstore
Subsequent response headers:
HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: Development/2.0
Date: Fri, 05 Apr 2013 20:33:08 GMT
Chrome + production server
Initial request headers:
Host: eduzabawy.appspot.com
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="sU9aqnqEf67eZFpS7BKSMw\075\075"; session=eyJfc2lkIjoieFlGWlJLMnRwSHJuOVFCb1haTnJLUCJ9|1365194193|2a13cd9eb7aceeb40c43bd82a763d893436d9f1f
Range: bytes=0-
Initial response headers:
HTTP/1.1 206 Partial Content
Cache-Control: public max-age=100000000
ETag: blobstore
Content-Type: audio/mpeg
Content-Range: bytes 0-4636/4637
Date: Fri, 05 Apr 2013 20:36:35 GMT
Server: Google Frontend
Transfer-Encoding: chunked
Subsequent requests and responses are the same as initial.

Your max-age seems too long and going over 3 years... I read from somewhere the maximum you should set in GAE is no more than 1 year.
Anyway, there's one more header you should try to set (Pragma: Public), which worked for me (I'm caching image from blobstore though, here's a few lines from my source code):
httpResponse.Header().Set("Cache-Control", "public, max-age=600")
httpResponse.Header().Set("Pragma", "Public")
blobstore.Send(httpResponse, project.ImageBlobKey)
By the way the above also cause Google to delivery your file from the edge cache, which really speed static resources up a lot!

Related

Chrome re-downloading same images each time in same session

I'm new to React and I'm trying to serve some files from either my public folder or any remote URL. No matter where I request the images from, my browser always re-downloads same images over and over again. For example (though this applies to all images in my React app), I change something in my state that creates an image object with some src (just a regular <img src...>, nothing special). Then I do something that causes another image to load the same resource. Browser should normally serve the image immediately from cache, but it instead downloads the same image again. Here are the request/response headers for one of the images (but as I said it happens with all images regardless of them being served from localhost or a remote host):
Request URL: http://localhost:3000/images/content-icons/small/button-question#2x.png
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:3000
Response Headers:
Referrer Policy: no-referrer-when-downgrade
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Connection: keep-alive
Content-Length: 479
Content-Type: image/png
Date: Sun, 01 Mar 2020 10:03:41 GMT
ETag: W/"1df-1707cbf1a8e"
Last-Modified: Tue, 25 Feb 2020 14:27:43 GMT
X-Powered-By: Express
Request Headers:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Host: localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36
This problem is occuring on Chrome (v80) and I've triple-checked that Disable cache checkbox is not checked. Apparently, there's no problem with Safari; it caches and serves from memory correctly.
What is going on with Chrome and caching?

Yeoman,Grunt, AngularJS 404 cannot Post /

I have this little angular app on the frontend which is a food list. So write a food and click submit and it will show the list.
When I add a food I query my backend wich is a sails app at localhost:1337 and it gets updated. The problem is I get redirected to
localhost:9000/#/food and get 404.
This is the faulty request
POST / HTTP/1.1
Host: localhost:9000
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image /webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Content-Type: application/x-www-form-urlencoded
Cookie:sails.sid=s%3A8gIjNxaZVE9dMr7nonXJzEaQ9hUcvcHm.Sp0K6ezep%2F7Y%2BV6TivtdRxqiBV 2S1LdH2IDNPWS9Ikk
Origin: http://localhost:9000
Referer: http://localhost:9000/
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id: 137B2031-138E-4B6B-A3AE- FB8EE96E9015
HTTP/1.1 404 Not Found
Connection: keep-alive
content-length: 14
Content-Type: text/html; charset=utf-8
Date: Mon, 23 Feb 2015 12:21:51 GMT
X-Content-Type-Options: nosniff
The other request that gets code 200 and update the server model looks like this:
OPTIONS /food HTTP/1.1
Host: localhost:1337
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers: accept, content-type
Access-Control-Request-Method: POST
Origin: http://localhost:9000
Referer: http://localhost:9000/
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-DevTools-Emulate-Network-Conditions-Client-Id: 137B2031-138E-4B6B-A3AE- FB8EE96E9015
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type, access-control-allow-origin, authorization,X-Requested-With
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
Access-Control-Allow-Origin: http://localhost:9000
Allow: GET,POST,PUT,HEAD,DELETE,TRACE,COPY,LOCK,MKCOL,MOVE,PURGE,PROPFIND,PROPPATCH, UNLOCK,REPORT,MKACTIVITY,CHECKOUT,MERGE,M- SEARCH,NOTIFY,SUBSCRIBE,UNSUBSCRIBE,PATCH,SEARCH,CONNECT
Connection: keep-alive
Content-Length: 175
Content-Type: text/html; charset=utf-8
Date: Mon, 23 Feb 2015 12:21:51 GMT
set-cookie: sails.sid=s%3A_kBdyRZgZ23Gh9YLkZfWBgnMody- jq-S.IY71%2BhJiBxTd19YIG2tgS2EOn1LPT%2BD9QAEQWtVB%2FbE; Path=/; HttpOnly
X-Powered-By: Sails <sailsjs.org>
At first I was looking at sails but I have CORS enabled and everything just like this:
https://github.com/tarlepp/angular-sailsjs-boilerplate/blob/master/backend/config/cors.js
So maybe it's more an angular issue. The request that fails is from the frontend to itself so just a redirect on itself when it has been updated on the server. I don't get why the request is denied...
If you want to take a look at the code:
http://okamuuu.hatenablog.com/entry/2014/04/10/135240
Issues seem the same as this Yeoman, Grunt, AngularJS and error 404 on POST form but that doesn't help me
Well, apparently your request is going to the port 9000:
Host: localhost:9000
Yet you said your app is running at port 1337.
So, in your $http requests, you need to specify the port. Otherwise, it will use the port your browser is currently connected to (9000) and there's no app there!
So, instead of
$http.get('/someUrl')
Try
$http.get('http://localhost:1337/someUrl')

How to avoid infinite loop when trying to load a 404-Not-Found favicon in Chrome?

I've read that Chrome keeps asking for the favicon in each page it visits (link), and if it doesn't find it (404 Not found) then Chrome enters in a infinite loop.
I'm afraid that is happening to my app, although it works fine with Firefox or Safari. I haven't found a way to prevent this after go through all the forums I could find.
The http headers before the problematic request is:
GET /url?file_id=0B0orkZUr6JxAdmViVmNuTG5XbFU HTTP/1.1
Host: glinksapp.appspot.com:443
Accept: image/webp,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nW31wx9PEvsqASLQKFZts0Ux1pWFwk...[cut]
Referer: https://www.google.es/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
X-Purpose: Instant
HTTP/1.1 302 Found
content-length: 0
content-type: text/html
date: Sun, 14 Jul 2013 08:59:56 GMT
location: https://drive.google.com/#folders/0B0orkZUr6JxAVk9xT3QxcXBpdWs
server: Google Frontend
status: 302 Found
version: HTTP/1.1
And this is the infinite loop in Chrome:
GET /favicon.ico HTTP/1.1
Host: drive.google.com:443
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: NID=67=fwmd6KsM_Y0xNrRMQlSSpVVmsKTgAi8v4AlG9A...[cut]
PREF=ID=ad9194453b59885b:FF=0:LD=en:TM=1373791886:LM=1373792185...[cut]
SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nWZBxbrbYxeGjE4p130PeYTaQhalIhrt6T-...[cut]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
HTTP/1.1 404 Not Found
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-encoding: gzip
content-length: 117
content-type: text/html; charset=UTF-8
date: Sun, 14 Jul 2013 08:59:56 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: GSE
status: 404 Not Found
version: HTTP/1.1
x-chromium-appcache-fallback-override: disallow-fallback
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
If you refresh the page, the app comes out from the loop.
My Java app's url is http://glinksapp.appspot.com and is hosted in Google App Engine. It is a drive app to open link files (webloc, url...) directly in Google Drive (something not provided by Google by default).
The question is: how to avoid entering in the 404 'Not found' loop when the app tries to reach 'drive.google.com/favicon.ico'?
Thx in advance.
Chrome and other browsers automatically request the favicon, but they don't enter an infinite loop when they get a 404 (which happens on a lot of sites, so that would be a gigantic problem). The link you posted says that Chrome on Android may request the apple-touch-icon files as well, but that's okay.
The HTTP 404 response you've pasted into your question looks totally fine. Your 302 redirect also looks fine. So I suspect the problem you're experiencing is something else, not related to the favicon.

Browsers Not Receiving From Server

I'm writing a simple webserver and right now I'm just trying to set up a generic
response to see that it's working. Right now, it's only been working on Firefox and not
on Chrome or Opera. Below are some of the requests I've gotten and a generic response is at the end. Is there a line I'm missing in the response? Is there really a generic response to get the server up and running?
I see that the requests have "Connection: keep-alive", so I tried leaving the connection open for a few seconds, and that didn't seem to help. I tried sending the data separately from the response header and that didn't really help either.
GET / HTTP/1.1
Host: 192.168.1.128
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
GET / HTTP/1.1
User-Agent: Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.15
Host: 192.168.1.128
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
GET / HTTP/1.1
Host: 192.168.1.128
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.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
Response here:
HTTP/1.0 200 OK
Date: Sun Apr 14 15:13:36 2013
Server: server_th
Content-Type: text/html
Content-Length: 40
Connection: close
<html><body><h3>Hey!</h3></body></html>
Your response has no body, so you will see a blank page. Besides, it seems to be lacking the trailing CRLF, but I am not sure whether it is due to copy-paste.
Check the HTTP specs.
EDIT: in the updated response, body length is actually 39, although it is declared 40. could it be that the client is waiting for remaining payload?

Firefox 3.6.13 configuration for spnego authentification

I'd like to access to a web application which requires spnego authentification.
This application is running on a network on which i'm connected by VPN connection. Proxy not used.
It works fine under IE6/7/8, Chrome but not firefox 3.6.13
The matter on firefox is: I don't have the prompt message box to enter username and password
To configure my FF, i applied the following instructions, adding the domain name to the trusted and delegation uris fields.
Trying to access to the application, i get the following error message:
A browser did not respond to authentication challenge sent by a server.
Most probably your browser is not configured properly to handle SPNEGO authentication challenge or does not support SPNEGO.
Please, contact your System Administrator to deal with the problem.
Using TCPMon to get an overview of the informations received:
GET /AppName HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/ HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/logon HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
Location: http://app.domain:8182/AppName/
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
0
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0
Location: http://app.domain:8182/AppName/logon
Content-Type: text/html
Content-Length: 0
Date: Tue, 14 Dec 2010 16:16:28 GMT
HTTP/1.1 401 Non-Autorisé
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
WWW-Authenticate: Negotiate
Connection: close
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
4b9
I've checked for the other browsers and i got the same informations.
Do someone have an idea why FF can't interprete it, prompt a dialog box or enter the application ?
Thanks in advance for any help.
Best regards.

Resources