@edgaral... Thank you for the followup. I'm evaluating GCloud while doing my friend a favour and building a website for his bar. This is a very small project but serve the purpose of evaluating the state of GCloud when it comes to the JAM stack. So far it's been uphill, with rudimentary functions missing and even if firebase is meant to fill this gap, it's comes with technology trade offs that are not acceptable in a commercial of high profile project. I will continue to investigate work-arounds but as this is a side-project, that I do in my spare time, I will not be able to respond on a day to day bases - more likely it will be weekly.
Currently my main obstacle has been redirects (301, 307, 308). I'm not the only one with this issue, Server Fault <https://serverfault.com/questions/790388/google-cloud-https-loadbalance-how-to-force-http-to-https> , medium.com <https://medium.com/google-cloud/google-cloud-platform-redirecting-http-traffic-to-https-f63c1d7dbc6d> , blog.realkinetic.com <https://blog.realkinetic.com/http-to-https-using-google-cloud-load-balancer-dda57ac97c>, etc. Rather than setting up entire VM just to do redirects <https://github.com/RealKinetic/http-to-https>, I will look into using Functions <https://cloud.google.com/functions/docs/> at a later stage when I have got everything else to play nicely. Even though it's goes against the principles of serverless applications. But really, a load-balancer is a HTTP server that route connections to the appropriate backend. Currently GCloud load-balancer can do the following: - Negotiate HTTPS for one domain on port 443, both for IPv4 and IPv6. - Route connections for any domain to different backends depending on path - Automatically deploy backend content to gcloud CDN (at least when using a Cloud Storage bucket). It seems like an obvious omission that it can not do: - Respond with 301 from HTTP to HTTPS. - Respond with 307 or 308 from one to domain to another. This is simple configuration options in NGINX, Apache and IIS. Why is gcloud load-balancer so handicapped? Creating certificates was a mystery without firebase but finally certbot-dns-google <https://certbot-dns-google.readthedocs.io/en/latest/> solved it. Firebase issues involves redirects being sub optimal. E.g. http://skovbaren.dk -> https://skovbaren.dk/ -> https://www.skovbar.dk/ Firebase also doesn't support IPv6 - which isn't a big deal, just odd. Firebase requires a client-side library in an app. This both adds to the page load, the complexity of the app, and probably needs to be updated from time to time, which means re-deployment and invalidating caches for something I do not use. I understand the reason to make all extra functionality easy to use/consume but in this case and in an enterprise app, I would not want it at all. Unfortunately it's also a security risk. Firebase requires the firebase token to be in the client-side javascript code. I can't really assess if this is a security issue but I guess if I'm not careful with my firebase settings - it can be! All I can say for sure is, It's easily retrievable by anyone with a web browser. CDN cache invalidation - the index.html page is updated before javascript assets - I currently deploy via gitlab CD. Deploying: stage: deploy only: - master script: - yarn run generate - yarn add firebase-tools - echo "Show files to deploy:" - ls -al dist/ - ls -al dist/_nuxt/ - npx firebase deploy --token $FIREBASE_TOKEN I currently run everything in firebase and then reverse engineer the settings made in GCloud. Fortunately this is possible and not a black box. GCloud administration tools are powerful but has yet to catch up with Microsoft Azure - I'm not using AWS voluntarily ever, since their default HTTP buckets HTTP headers are broken - chromium bug 809891 <https://bugs.chromium.org/p/chromium/issues/detail?id=809891#c13> Thats all for now - thank you for listening. PS. I hope all of the links survives the trip to various google groups readers. If not, let me know and I'll post them in the clear. On Saturday, August 25, 2018 at 1:37:42 AM UTC+2, [email protected] wrote: > > @Jon, yes the documentation can sometimes be hard to follow. The > information you provided is although already in our documentation, albeit > you would have to track it down in a few clicks. > > 1) https://cloud.google.com/storage/docs/hosting-static-website > > 2) Read the Caution notice about HTTP/HTTPS, which brings you here: > > https://cloud.google.com/storage/docs/troubleshooting#https > > 3) Follow the link to the troubleshooting which would direct you to how to > serve HTTPS, which provide the solution of using Firebase hosting: > > https://firebase.google.com/docs/hosting/ > > Let us know how we can make improvements to our documentation regarding > the above documentation, any feedback will be redirected to the appropriate > team to review. > > @John, Can you confirm exactly what would be required as a functionality? > Are you referencing to the redirection of HTTP to HTTPS when hosting a > static website hosted in Google Cloud Storage __without the need of using a > Load Balancer and a CDN__? > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/70cdada1-184d-4fab-acdd-fdc8ff93af68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
