I'm trying to understand app.yaml a little better.
GCP docs recommend creating a handler for your images like this:
# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
static_files: \1
upload: .+\.(gif|png|jpg)$
application_readable: true
However I use the much simpler:
- url: /assets/images
static_dir: assets/images
I would like to understand the extra parameters and regular expressions Google has used.
What are the differences between Google's and my handler?
PS at the moment my handler is working, but when I use the Google handler my images do not load.
The explanation is in the static_files row from the Handlers element table:
static_files
Optional. A static file pattern handler associates a URL pattern with
paths to static files uploaded with the application. The URL pattern
regular expression can define regular expression groupings to be used
in the construction of the file path. You can use this instead of
static_dir to map to specific files in a directory structure without mapping the entire directory.
Example:
handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
static_files: static/\1
upload: static/.*\.(gif|png|jpg)$
The url is the requested path while static_files and upload are real file paths relative to your app/service source directory, with \1 and .*\.(gif|png|jpg)$ respectively replaced by the url regex matching grouping value - whatever is inside the outer round paranthesis.
So a request to /a_file.gif will match the url regex, producing a a_file.gif grouping. Which will be replaced into static_files and upload as static/a_file.gif - the actual path of the file in your app source code.
With your static_dir config any file that exists under assets/images would be served if a matching request to /assets/images/<the_file> is made, regardles of what that filename is.
With a static_files config you can select only specific filenames to be served (that match the regex pattern) and you can make them appear with a different name and/or in a different path than the one where they really are relative to the app dir.
Your static_files config should be working if you make requests to the right path, like /assets/images/<some_file>.png for example (I assume that's where your image files exist).
But if you want, for example, to serve a file located under that assets/images dir but requested simply as /<some_file>.png (i.e. without that path prefix) you'd need to configure it differently:
# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
static_files: assets/images/\1
upload: assets/images/.+\.(gif|png|jpg)$
Also check that you don't have overlapping static_dir and/or static_files paths configured - that can cause obscure problems, see Static files are missing
Related
This React website is served on Google Cloud Platform
I want to edit an existing handler
- url: /(.*)$
static_files: public/\1/index.html
upload: public/.*/index.html
to get rid of warnings like this Static file referenced by handler not found: public/_ah/start/index.html
I have seen this solution, but I'm not quite sure how to use it in my case. Any ideas?
I tried option below, but it didn't work, build fails.
- url: /(?!.*\/_ah).*$
static_files: public/\1/index.html
upload: public/.*/index.html
An error in an application's app.yaml frequently causes the error static file referenced by handler not found. It basically means that one of app.yaml's static file handlers is diverting to a file that does not exist or is named wrongly.
You might be able to come up with a strategy if you have a technique of differentiating files from directories. You can achieve something like this by stating that all filenames must have extensions (and folders most not. in their names):
/optional/path/folder/ - serve index.html inside
- url: /(.*)/
static_files: public/\1/index.html
upload: public/.*/index.html
/optional/path/name.extension => files - serve them
- url: /((.*\/)*[^\/]+\.[^\/]+)$
static_files: public/\1
upload: public/.*
anything else is a folder - serve index.html inside
- url: /(.*)$
static_files: public/\1/index.html
upload: public/.*/index.html
Remember that all this depends on your directory.
Here is also app.yaml and structuring web services documentation that could help.
My application contains Angular and Php Yii2 framework.
I hosted my application on Google App Engine.
Here is the contents of my app.yaml file:
threadsafe: true
runtime: php55
api_version: 2
handlers:
# The root URL (/) is handled by the Go application.
# No other URLs match this pattern.
- url: /(.+)
static_files: \1
upload: (.*)
- url: /web-service/*
script: web-service/yii
- url: /
static_files: index.html
upload: index.html
My Yii2 library is available in web-service directory, but when I call REST API from the postman, it then returns a '404 page not found' error.
Am I missing something in my app.yaml file?
Please help me solve this issue. My API call is something like this:
https://abcxyz.appspot.com/web-service/web/user-registration/login-user
Several problems:
api_version: 2 - there is no such version presently, set it to 1. From the api_version row in the Syntax table:
At this time, App Engine has one version of the php runtime
environment: 1
the order of the handlers in app.yaml matters, the first one with a matching pattern will be used. Your url: /(.+) pattern will match all of your /web-service/* requests as well, so static files uploads will be attempted instead of the script(s) you're expecting. Re-order your handlers with the most significant patterns preceeding the less significant ones.
your script: web-service/yii entry might not be OK if other php files need to be served from the web-service dir (the web-service/yii will always be the one served, regardless of the requested script). Instead I'd use the handler suggested in the Example (assuming the script names always end with .php):
# Serve php scripts.
- url: /(.+\.php)$
script: \1
Always check the request entries in the development server logs as a starting point to debug request failures.
I have a ready php website. For that website I am writing app.yaml for google app engine.
I read so many answers but it doesnt help me.
I am facing problem with php files under various subfolders in libraries folder.
In index.php, i accept rss feed url and process it for full text feed by calling other php files. but getting this error.
/makefulltextfeed.php?url=https%3A%2F%2Fnews.google.co.in%2Fnews%3Fpz%max
=10&links=preserve&exc=&submit=Create+Feed was not found on this server.
How to write app.yaml for all php files which comes under various sub-folders??
Do i have to write handlers: for all individual php files??
I am stuck here for whole day.
I am new to this topic. So if you find this as stupid question please forgive me.
Here is my app.yaml
application: xxxx-xxxx-90212
version: alpha-001
runtime: php
api_version: 1
handlers:
- url: /
script: index.php
- url: /config
script: config.php
- url: /makefulltextfeed
script: makefulltextfeed.php
- url: /css
static_dir: css
- url: /js
static_dir: css
- url: /images
static_dir: images
I have php files in subfolder. How to write app.yaml for that.
As described here you can use this notation to match all root path, that ends with .php, to a php script
# Serve php scripts.
- url: /(.+\.php)$
script: \1
This config assume that each your URL ends with .php, you can modify url regex to catch all urls (I test only the regex but I think it's works :) )
# Serve ALL php scripts.
- url: /((.+\/).*)$
script: \1.php
Or you can simulate httpd mod_rewrite as described here.
(Question edited b/c I have realized it involves file type)
This file is 20kb. It is consistently taking > 1 second to serve.
http://www.adrenalinemobility.com/js/ss-symbolicons.js
Here is the same file with .css as it's extension:
http://www.adrenalinemobility.com/js/ss-symbolicons.css
It serves almost 1 whole second faster.
Here is my app.yaml:
application: adrenaline-website
version: 1
api_version: 1
runtime: python27
threadsafe: true
libraries:
- name: jinja2
version: latest
handlers:
- url: /favicon\.ico
static_files: assets/favicon.ico
upload: assets/favicon\.ico
- url: /css
static_dir: assets/css
- url: /img
static_dir: assets/img
- url: /js
static_dir: assets/js
- url: /.*
script: web.APP
I've also tried this static_files line (before the /js handler), and it was slow too:
- url: /js/ss-symbolicons.js
static_files: assets/js/ss-symbolicons.js
upload: assets/js/ss-symbolicons.js
Ways I have observed this:
Chrome, Firefox (both on Linux) - from a DSL connection in Silicon Valley
wget, curl, etc from that machine.
Remotely wget and curl from a high-speed server at the University of Illinois
Remote web testing services like webpagetest (see below):
Here's a webpagetest waterfall graph that illustrates this problem - notice the one file has a huge TTFB: http://www.webpagetest.org/result/131101_ZQ_ZGQ/1/details/
If i manually set the mime_type to text, then it goes fast. application/javascript, application/x-javascript, text/javascript are all slow. Currently those files are serving without manually specified mime-type if you wish to test.
Some more info, as noticed by jchu:
The slow version serves with: Content-Length: 19973 and the fast version serves with: Transfer-Encoding: chunked
Still more details:
I usually get server 74.125.28.121. Someone on reddit got server 173.194.71.121 and it seems to have even serving speeds between them. So maybe it's server/location dependent?
Another post about this issue
Here is a pastebin with full curl logs of requests for both files
Here is another pastebin with just the timing information from ten requests on each file in a tight loop
Add mime_type: text to your JavaScript static resource.
Would need to look into what mime_type is being assumed, what what clever trick is being done for text vs other mime types...
I've been seeinig the same behavior.
GAE has some strange edge caching behavior for these javascript files. After the 4th or fifth consecutive request, the response time improves significantly (some type of edge caching of the gzipped content kicks in). In my experiments it's gone from around 1.2s -> 190ms
I've been able to reproduce this consistently across 3 GAE apps.
If you use Chrome, you can go to the DevTools settings and disable cache (while DevTools is open). Reloading the page a few times will get your javascript transfer times down to the reasonable numbers.
Google's edge cache probably has some logic where it determines it won't bother caching gzipped js files until they're requested frequently enough. This would appear to encourage you to write a script that constantly downloads your js files to ensure that they download a few hundred milliseconds faster. I suspect that the edge cache is smart enough to only cache for one region at a time though.
I'm facing a problem where a static file is showing up correctly on the local machine via dev_appserver.py but once uploaded to the server it doesn't show and gives me a 404 error.
The partial directory file structre is:
- static/
articles.html
images/*.png
The partial app.yaml file is:
runtime: go
api_version: go1
- url: /(articles\.html)
static_files: static/\1
upload: static/*.html
I then to access this via the http url appname.appspot.com/articles.html.
I downloaded the code after I put it on the appengine server to ensure that articles.html has actually been uploaded in the said directory, and it has. So the exact same file structre locally and on the server, but it gives a 404 on the server and works locally. I have the latest versions of the appengine. Any help on what I could be doing wrong?
thanks in advance
Sathish
Just putting this up for completeness ... I went back and tried various reasonable combinations again and found that this config works:
- url: /(articles)\.html
static_files: static/\1.html
upload: static/.*.html
It is ridiculous of me to make the claim now, but I remember attempting a regex for the "upload" entry earlier and it hadn't worked. So, I don't clearly know the issue, however, my best guess is that dev_appserver.py is probably taking some shortcuts to serve static files and not behaving exactly like the appengine would. I shall raise an issue on that and see if there is any resolution or clarification.