英文:
How to set Strict-Transport-Header for GRPC services
问题
我正在检查Strict Transport Header，它是用于为UI提供服务的Http端点。在GRPC服务中，不将头部暴露给互联网或直接提供给UI，这样做有意义吗？
如果有意义，那么如何为GRPC服务启用Strict Transport Header呢？
我看到Grpc可以通过响应发送trailing-metadata头部。
但是这样添加头部的方式正确吗？
这些服务是用Go编写的，我正在使用GRPC。
英文:
I was checking Strict Transport Header which Http endpoint serving to UI enables.
Does it make sense to have the headers in the GRPC services not exposed to internet or serving to UI directly?
If so, what will be the way to enable Strict Transport Header for GRPC services?
I have seen that Grpc trailing-metadata headers can be sent with the response.
But is it the correct way to add the header?
The services are written in Go and I am using GRPC.
答案1
得分: 2
HTTP严格传输安全性（HSTS）只有在客户端也支持的情况下才有用。gRPC客户端不支持HSTS，因此添加这样的头部不会增加任何价值。
如果客户端不支持HSTS，那么HSTS就没有用处的原因是，头部只是说“你应该只通过HTTPS访问此资源”，但是如果客户端忽略了这一点，它仍然可以继续进行普通的HTTP请求（假设服务器同时支持HTTP和HTTPS）。
此外，HSTS只在客户端至少访问过资源并记住了当时接收到的头部之后才起作用。这对于大多数服务器之间的通信是不成立的。
如果您想确保与gRPC服务和客户端之间的数据进行加密，您可以使用SSL/TLS，如https://grpc.io/docs/guides/auth/#using-client-side-ssltls中所示。
英文:
HTTP Strict Transport Security (HSTS) is only useful if the client also supports it. gRPC clients don't, so adding such headers doesn't add any value.
The reason why HSTS is not useful if the client does not support it, is because the headers only say "you should only access this resource over HTTPS", but if the client just ignores that, it can continue to make plain HTTP requests (assuming the server supports both HTTP and HTTPS).
In addition, HSTS only works after the client accessed the resource at least once and remembered the headers it received at that time. This isn't true for most server-to-server communications.
If you want to ensure that data to/from your gRPC services and clients is encrypted, you can use SSL/TLS as shown on https://grpc.io/docs/guides/auth/#using-client-side-ssltls.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论