I would like to amend a curious observation that I made.

When configuring gcloud DNS, if you only set an A/AAAA record to point to a 
subdomain and doesn't set up the apex domain, then naked domain requests 
will magically redirect to the subdomain. E.g. only setup www and then 
request for skovbar.dk -> www.skovbar.dk.

I forget if I was pointing to a public gcloud storage bucket or the 
load-balancer at this time (it was early on in my experimentation).

On Tuesday, August 28, 2018 at 5:14:35 PM UTC+2, Jon Ronnenberg wrote:
>
> Errata:
> Currently GCloud load-balancer can do the following:
>
>    - Negotiate HTTPS for one domain on port 443, both for IPv4 and IPv6.
>
> Should have been:
> Currently GCloud load-balancer can do the following:
>
>    - Negotiate HTTPS for *any* domain on port 443, both for IPv4 and IPv6.
>
> Domains are handled via Cloud DNS. DNS by nature can not do redirects but 
> can easily point several domains to the same IP address.
> Which in this instance is the same load-balancer, with two IPs (IPv4 and 
> IPv6). That the load-balancer can not redirect based on hosts is a
> huge oversight.
>
> On Tuesday, August 28, 2018 at 5:01:07 PM UTC+2, Jon Ronnenberg wrote:
>>
>> @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, edgaral...@google.com 
>> 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 google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
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/74038c86-7b44-442e-8d93-128fd93db19d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to