Comments (5)
use HTTP1 with an Upgrade header to allow upgrading to HTTP2.
Is any application actually using HTTP1 with an Upgrade header to HTTP2? I am skeptical that it is worthwhile to spend time on this unless we see some evidence it is actually done in the real world. I've literally never seen it done IRL.
from linkerd2.
accept-side
Let's distinguish between the two cases of accept-side traffic: public traffic from outside the pod, and private traffic from the service within the same pod that the proxy is in. I agree that the plan makes sense w.r.t. the private traffic we accept from the service within the same pod as the proxy. And I agree in the short term it is OK for the public traffic from outside the pod. However, in the long term I think the plan makes less sense.
In particular, the long-term plan is to provide automatic TLS and to enforce that TLS is used by default. That means that, in the long term, absent any annotations, we need to reject any non-TLS public traffic. While the annotation to opt into accepting non-secure public traffic could be a boolean flag, if the user has to add an annotation for plaintext traffic to work anyway, we might as well make the annotation value be the name of the plaintext protocol: HTTP or whatever. Then we wouldn't have to do the sniffing on the public listener, which would be better for security, predictability, and reliability.
from linkerd2.
The destination service would be updated to report back hints about what protocols a destination supports. A proposed new destination service:
Do we really need to have per-address protocols? Let's see a motivating example if so. The destination service was designed to be zero-trust like DNS; that is, even if the Destinations service lies to the proxy, there will be no security problem (w.r.t. TLS). This new design proposes Destinations to become a highly-trusted service because it would control whether we attempt to secure the connection with TLS or not.
Although I may be missing some of the target use cases, as far as I understand things now it makes more sense for there to be a Protocols
service that maps every Authority
to a (Scheme, Authority)
. Then the Destination
lookup would map (Scheme, Authority)
to (IpAddr, Port)
; i.e. Scheme
would be an input to Destinations
, not an output of Destinations
.
from linkerd2.
@seanmonstar What should we do with this issue? GitHub says 0/13 tasks have been done but that seems far from accurate: new tasks were identified and many tasks were already done. Should we just close this in favor of having a separate GitHub issue for each currently-outstanding issue?
from linkerd2.
I'd say this could be closed, as it is not an accurate record of how this was implemented.
from linkerd2.
Related Issues (20)
- `duplicate metrics` in destination controller
- Linkerd is giving 200 or 400 responses for the same un-encoded url request depending on the situation HOT 5
- Linkerd destination repeatedly logging endpoint profile translator errors HOT 3
- Linkerd proxy fails to connect to other proxy HOT 2
- duplicated copies of trust anchor certificate HOT 1
- IPv6 semantics differ from Kubernetes without Linkerd HOT 3
- Helm install documentation refers to incorrect repo HOT 1
- Traefik Router unable to communicate with meshed services when linkerd inbound policy is all-authenticated. HOT 5
- Policy controller fails to watch resources. HOT 2
- Multi-cluster demos using TrafficSplit object are not working HOT 1
- Proxy trying to connect to no-longer available endpoints HOT 3
- .
- Enable OpenSSF Scorecard to enhance security practices across the project
- "Operation not permitted" error in linkerd-proxy on edge-24.6.4 HOT 8
- Better documentation on the expectations for `networkValidator.connectAddr` for `linkerd-control-plane` helm chart values HOT 4
- Linkerd Destination Pod Unhealthy Warnings
- Healthchecks/livenessProbe does not pass when using HTTPS scheme HOT 3
- The "Debugging HTTP applications with per-route metrics" task in the documentation is broken and needs updating
- Not all gRPC errors should be retried HOT 2
- Traffic split not working with ExternalName services / services in different namespaces HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from linkerd2.