I've set up a fresh hosting project (not using any custom domain at the moment) and split up some of my js files expecting them to be served via http2 (as described in firebase blog posts it should be enabled by default?) However protocol still shows up as http/1.1. Am I missing something? Do I need to add entry in my config files to force http2?
DEMO: https://asimetriq-com.firebaseapp.com/
Works for me, see attached screenshot.
It may mean that you have some transparent proxy that does not support HTTP/2 in the network hops from your client to the server.
Also, from time to time, browsers may downgrade the protocol they are using to collect statistics about protocol performances to be able to compare them.
Related
Is it possible to enable HTTP2 in cloud foundry using NGINX buildpack or any? I understand that GoRouter will not support HTTP2 but not sure if there is any workaround for this?
My original requirement is to serve large JS file from Cloud Foundry so to improve performance looking for enabling HTTP2.
Thanks,
Not exactly the same question, but the solution here applies: https://stackoverflow.com/a/55552398/1585136.
If you have the need for public clients (i.e.clients outside CF) to connect to your app, you need to use TCP routing. If your provider doesn't enable this by default, find another provider (see this list of public providers, hint Pivotal Web Services will provide TCP routes upon request) or self host.
If you only need to use HTTP/2 and/or gRPC between apps running on CF, you can use the container to container network. When you talk app to app, there are no restrictions (so long as you properly open required ports). You can use TCP, UDP and any protocol built on top of those. There some details about how this works here.
You'll also need the Nginx http_v2_module. This is a very recent addition and isn't yet in a build of the Nginx or Staticfile buildpack as I write this. It's should be, if everything goes right, in the next release though. That should be Nginx buildpack 1.1.10+ and Staticfile buildpack 1.5.8+.
My original requirement is to serve large JS file from Cloud Foundry so to improve performance looking for enabling HTTP2.
It might, it might not. Your mileage may vary. HTTP/2 isn't a silver bullet. This explains this well.
https://www.nginx.com/blog/http2-module-nginx/
I run Apache over HTTPS and can see in the log file that a HTTP/1.1 request is made for every single file of my repository. And for every single file, the full URL is disclosed.
I need to access my repository from a location where I don't want sysadmins to look over my shoulder and see all these individual URLs. Of course I know they won't see file contents since I am using HTTPS or not HTTP, but I am really annoyed they can see URLs and as a consequence, file names.
Is there a way I can hide or encrypt HTTPS urls with SVN?
This would be great, as I would prefer not having to resort using svn+ssh, which does not easily/readily support path-based authorization, which I am heavily using.
With HTTPS, the full URL is only visible to the client (your svn binary) and the server hosting the repository. In-transit, only the hostname you're connecting to is visible.
You can further protect yourself by using a VPN connection between your client and the server, or tunneling over SSH (not svn+ssh, but an direct ssh tunnel).
If you're concerned about the sysadmin of the box hosting your repository seeing your activity in the Apache logs there, you have issues far beyond what can be solved with software. You could disable logging in Apache, but your sysadmin can switch it back on or use other means.
Last option: if you don't trust the system(s) and/or network you're on, don't engage in activities that you consider sensitive on them. They can't see something that isn't happening in the first place.
I'm writing a web app in Go. Currently I have a layout that looks like this:
[CloudFlare] --> [Nginx] --> [Program]
Nginx does the following:
Performs some redirects (i.e. www.domain.tld --> domain.tld)
Adds headers such as X-Frame-Options.
Handles static images.
Writes access.log.
In the past I would use Nginx as it performed SSL termination and some other tasks. Since that's now handled by CloudFlare, all it does, essentially, is static images. Given that Go has a built in HTTP FileServer and CloudFlare could take over handling static images for me, I started to wonder why Nginx is in-front in the first place.
Is it considered a bad idea to put nothing in-front?
In your case, you can possibly get away with not running nginx, but I wouldn't recommend it.
However, as I touched on in this answer there's still a lot it can do that you'll need to "reinvent" in Go.
Content-Security headers
SSL (is the connection between CloudFlare and you insecure if they are terminating SSL?)
SSL session caching & HSTS
Client body limits and header buffers
5xx error pages and maintenance pages when you're restarting your Go application
"Free" logging (unless you want to write all that in your Go app)
gzip (again, unless you want to implement that in your Go app)
Running Go standalone makes sense if you are running an internal web service or something lightweight, or genuinely don't need the extra features of nginx. If you're building web applications then nginx is going to help abstract "web server" tasks from the application itself.
I wouldn't use nginx at all to be honest, some nice dude tested fast cgi go + nginx and just go standalone library. The results he came up with were quite interesting, the standalone hosting seemed to be much better in handling requests than using it behind nginx, and the final recommendation was that if you don't need specific features of nginx don't use it. full article
You could run it as standalone and if you're using partial/full ssl on your site you could use another go http server to redirect to safe https routes.
Don't use ngnix if you do not need it.
Go does SSL in less lines then you have to write in ngnix configure file.
The only reason is a free logging but I wonder how many lines of code is logging in Go.
There is nice article in Russian about reverse proxy in Go in 200 lines of code.
If Go could be used instead of ngnix then ngnix is not required when you use Go.
You need ngnix if you wish to have several Go processes or Go and PHP on same site.
Or if you use Go and you have some problem when you add ngnix then it fix the problem.
I am using google hosted javascripts libraries,(jquery ,jquery-ui & other google jsapi),and I noticed that these scripts can be accessed by both http & https schema.Now ,I want to know that what are the effects of using http or https schema to access these google hosted scripts , and for my projects ,it's just an ordinary websites ,using http as default schema, so ,what should I do ,http or https? Is there any performance issue between the two ?
https does affect performance negatively, as encryption and security negotiation aren't trivial tasks. In the vast majority of cases this performance cost is not significant enough to outweigh its benefits.
Remember that SSL also secures the identity of the web server and not just the channel.
If a "man-in-the-middle" spoofed the address of your script's location (for instance), https would prevent you from unknowingly executing unintended scripts. http would not.
Check this out: HTTP vs HTTPS performance
The performance issue is rather small considering todays hardware and internet bandwidth. Personally I try to use the same protocol for all data used by one page (or iframe / frame), meaning scripts, CSS, images etc.
Data transferred over SSL will not be cached by the visitor's browser, instead will be downloaded each time a page is loaded.
Using SSL / HTTPS is recommended if a page contains sensitive data, personal data, or offers interactions like contact forms etc. Buying and installing a SSL certificate is justified in those cases.
Google analytics for example first checks which protocol your page uses, then uses the same protocol for downloading its scripts.
we have a site (https://oursite.net) in which we display a videostream hosted on http (http://someserver.com). The site needs to be hosted on https, and we don't control the video, so I'm assuming it needs to be on http. we recently added the option to play the stream through the silverlight asp:MediaElement, which works perfectly fine in our test environment (on http) but doesn't work in production (https).
The info on the web is somewhat confusing as I'm having a hard time differentiating between how this stuff worked at different stages in the silverlight development (seems to have been a bit to and fro)
Is this setup possible at all (hosting the player on https but playing a stream on http) with some sort of policy file?
in that case: does this policy file need to be hosted with the silverlight app (on https) or where the streams are located (http)
Thanks for your time
Andreas
You are running into a cross-scheme violation unfortunately. The stream would need to match the same scheme (https) as the hosting application. Unfortunately most streaming isn't available in HTTPS.
Can you check the enableHtmlAccess property on the object tag to make sure it is true? Most media players end up using the HTML DOM bridge to communicate with the web page.
It's also likely that there is a cross-scheme issue: you should try and optimize for all assets being on the same scheme (HTTP or HTTPS).