I'm looking at various pages about dispatch.yaml, most of which contain similar information and examples:
https://cloud.google.com/appengine/docs/flexible/nodejs/how-requests-are-routed#routing_with_a_dispatch_file
https://cloud.google.com/appengine/docs/python/config/dispatchref
https://cloud.google.com/appengine/docs/go/config/dispatchref
etc.
I happen to be using node.js on GAE Flexible Environment, but I think it would be the same for every language and environment.
The problem is that these pages don't really specify how dispatch.yaml works. In particular:
Are rules applied in the order given? I'm assuming that the first matching rule is the one used, but nothing seems to say so.
Do leading glob (wildcard) characters match only the domain name, or could they match the first part of the URL's path? If the rule is */hello, would that match myapp.appspot.com/path/hello? I'm guessing not, based on some vague hints in the docs, but it isn't very clear.
If no rule in dispatch.yaml matches the URL, will it be routed to the default service? I would think it would have to, but again, these pages don't say.
Do URLs get rewritten based on the rules before they're sent to the service? If the rule is */path/* and the URL is https://myapp.appspot.com/path/hello, will the service see it as /path/hello or as /hello? I'm guessing the former.
I'm doing some trial and error now, so I may be able to answer my own question soon. I'm also submitting this to Google through their documentation feedback system.
Things I know so far:
Yes, rules are tried in order. So for example, if you want one URL to go to a specific service, and all other URLs to go to another service, you should specify the specific one first:
dispatch:
- url: "*/specific"
module: specific
- url: "*/*"
module: general
If you put those rules in the opposite order, module specific will never be used, because the URL /specific will be caught by the wildcard rule.
Unknown
Yes. You can test this by making a request not matching any dispatch.yaml rule and watching the default's service logs.
No rewriting. If the rule is */path/* and the actual URL is https://myapp.appspot.com/path/hello, your service should still handle /path/hello, not /hello.
Just to fill in the blank (feel free to paste this into the accepted answer):
No. It only matches the start of the path.
I created two apps with the following resources:
default -> /abc/def/test.html -> <h1>default</h1>
other -> /abc/def/test.html -> <h1>other</h1>
And 1 route:
<dispatch>
<url>*/def/*</url>
<module>other</module>
</dispatch>
When I hit {app engine}/abc/def/test.html I got "default"
Related
I have this:
- url: "awesome.com/*"
service: awesome
- url: "www.awesome.com/*"
service: awesome
Is possible to do this? to achieve same as above?
- url: "*.awesome.com/*"
service: awesome
No, what that last option you mentioned would do is map all subdomains of awesome.com to the service awesome, as you can see in this example corresponding to mapping subdomains in the documentation.
Here you have more information about mapping custom domains.
Yes, it's possible to do that. But it won't be equivalent with what you have now:
it won't match your top-level domain awesome.com which is matched by your current 1st rule
it'll match any <blah>.awesome.com subdomain, your current set of rules only matches the www.awesome.com subdomain
If indeed you want to send requests for both the full domain as well as all its subdomains to the awesome service you can achieve that simply by the custom domain mapping/config itself (which you need to do explicitly for the domain and each subdomain anyways), no need for a dispatch file.
Note that you'd still need to deploy a default service, see Why do I need to deploy a "default" app before I can deploy multiple services in GAE?. Might as well just let the awesome service be the default one in this case, less confusing and less room for trouble IMHO.
I have two very simple services set up (in python) on google app engine. I have a site which has been up for a while as the defualt service of my example project, and I just deployed another service, lets call it foo. I have dns forwarding working for the default service, so I can go to example.com (which I own in this hypothetical scenario) and see my default service. I can also go to foo.example.appspot.com and see my foo service, which works at the url.
I have also registered another domain, let's call it foo.com. What I want is for foo.com to use my foo.example.appspot.com service. To make matters trickier, foo.com has a bunch of sub-domains of it's own, so I need x.foo.com to go to my foo service as well (and even x.y.foo.com would be ideal, but if that is hard I can work around that one easily enough by just substituting out another character so it would be x-y.foo.com or something along those lines).
I'm pretty new to web dev (which is honestly a generous description for this simple project), but Iv'e spent a while reading and googling and haven't found a solution to this, so any advice would be helpful. My last resort would be to un-service-ify (if you will) the two services, and just bundle it all up into one big main.py which routes differently depending on the domain, and then point both domains at the default service. The big downside to this is that I already have everything working with services (which seems like a better approach).
I expect to get very few users so scaling isn't really an issue (though it's always interesting to learn about).
EDIT:
attempted to create a dispatch.yaml file to solve this as follows:
dispatch:
- url: "foo.com"
module: foo
- url: "*.foo.com"
module: foo
but when I run appcfg.py -A <project_id_here> update_dispatch . it says
Error parsing yaml file:
Unable to assign value 'foo.com' to attribute 'url':
invalid url 'foo.com'
in "./dispatch.yaml", line 3, column 10
Yes, it should be possible. I didn't actually use 2 different top-level domains, but the development console appears to be ready to accept a second one (I can't actually check as I don't own a 2nd domain). Follow the Adding a custom domain for your application procedure.
Pay special attention to the Wildcard mappings section - since your foo.com domain already has sub-domains in use you can't use wildcards at/above those sub-domains, you'll have to specify the desired subdomains.
The procedure only maps (sub)domains to the app as a whole, not to individual services/modules. You'll also have to use a dispatch file, to route the specific subdomains to the corresponding modules/services. You can find examples here: https://stackoverflow.com/a/32103486/4495081 and https://stackoverflow.com/a/34111170/4495081 (the last one has rules to allow the module to work on the custom domain, on appspot.com and on the local development server).
I got it to work following The links in the answer. My dispatch file wound up looking like this:
dispatch:
- url: "foo.com/*"
module: foo
- url: "*.foo.com/*"
module: foo
I'm developing an application with webapp2 to be deployed on Google App Engine. URLs will always be preceded by a language identifier, such as:
http://www.mydomain.com/en/foo
http://www.mydomain.com/en/bar
I would like to automatically redirect any request that doesn't start with a language identifier to the corresponding English version. For example, the following URLs should redirect to the URLs above:
http://www.mydomain.com/foo
http://www.mydomain.com/bar
Currently, I'm using webapp2_extras to set up one redirect for every possible URL, which is creating a lot of code duplication. The problem is that, to my understanding, URL redirection in webapp2 needs to be defined on a per-handler basis.
How can I go about redirecting all requests that don't match a regular expression (language identifier in my case) to the corresponding modified URL (adding en/ in my case)?
what you are searching for is a middlware. here an example.
Old question but it seems like setting routes and catching exceptions would be a good way to go for this: http://webapp-improved.appspot.com/guide/exceptions.html#exceptions-in-the-wsgi-app
Routes for the http://www.mydomain.com/en/foo cases and any http://www.mydomain.com/foo cases will be a 404 exception, which you can address with a handler, redirecting to the appropriate "en" page.
I have a java app running on Google App Engine... I'd like to make the trailing slash optional for directories... so navigating to www.domain.com/test and www.domain.com/test/ would yield the same thing.
How do I achieve that?
I know about the app.yaml configuration file but I am running a Java app not python..
See this post. Works for me, though looks like a hack. I think it worth posting issue to google, as thee servlet specification requires adding trailing slashes when attempting to find a proper welcome-file.
The easiest way to do this would be to create a filter that intercepts requests and appends the forward slash if necessary. Generally it's better to send a redirect rather than serving the same content, so you don't end up with two canonical URLs for everything, and all your contents indexed twice.
What constitutes a 'directory' depends on your application, of course, and there's no hard and fast rule for figuring that out.
I'm not aware of a solution for implementing custom persistent vanity URLs (my term, not sure if thats what they're really called) in DotNetNuke. Does anyone know of a solution? It can be configuring the core, using a third party module, or a suggestion of how to write it from scratch.
Here is what I'm thinking:
I want to point people to: http://mywebsite.com/awesome
I want the underlying URL to be http://mywebsite.com/genericpage.aspx?key=awesome&etc=etc
I don't want the URL to redirect. I want the user to see http://mywebsite.com/awesome only.
Essentially I'd envision an administrator being able to create these vanity URLs and specify what the vanity URL is and what the underlying URL is.
The closest thing, out of the box, is to define your friendly urls in SiteUrls.config found in the DotNetNuke root.
This way:
you point people to:
http://mywebsite.com/awesome.aspx
you have an underlying URL
http://mywebsite.com/Default.aspx?tabid=ID&etc=etc
users see:
http://mywebsite.com/awesome.aspx
Main restriction is that you will have an .aspx extension.
SiteUrl.config rules look like this:
<RewriterRule>
<LookFor>.*/awesome.aspx</LookFor>
<SendTo>~/default.aspx?tabid=ID&etc=etc</SendTo>
</RewriterRule>
Rewriter rule matches incoming url to a regular expression in the LookFor section, and sends it to an underlying url in the SendTo section. You need to be careful with the XML escape character '&' in the querystring parameters.
3rd party extensions like URL Master provide much more fine grained control, and you can have a global friendly url scheme based on page names, with or without .aspx extensions. Nevertheless, a simple "one url at a time" approach can be safer if you have custom modules with URL dependencies.
ActiveSocial supports these and I thought I saw something about support for this in Version 2.x of IFinity's URL Master, but I can't find anything on it now.