Hướng dẫn về HTTP Headers trong YARP

Headers (tiêu đề) là một phần rất quan trọng trong việc xử lý các HTTP request và mỗi header có ngữ nghĩa và cân nhắc riêng của nó. Hầu hết các headers được proxy mặc định, mặc dù một số headers được sử dụng để kiểm soát cách request được gửi đi sẽ được tự động điều chỉnh hoặc xóa bởi proxy. Các kết nối giữa client và proxy và giữa proxy và destination là độc lập. Do đó, các headers ảnh hưởng đến kết nối và transport phải được lọc. Nhiều headers chứa thông tin như tên miền, đường dẫn, hoặc các chi tiết khác có thể bị ảnh hưởng khi một reverse proxy được đưa vào kiến trúc ứng dụng. Sau đây là một bộ sưu tập hướng dẫn về cách các header cụ thể có thể bị ảnh hưởng và cần làm gì với chúng.

Lọc headers trong YARP

YARP tự động xóa các request và response headers có thể ảnh hưởng đến khả năng chuyển tiếp request đúng cách của nó, hoặc có thể được sử dụng một cách độc hại để bỏ qua các tính năng của proxy. Danh sách đầy đủ có thể được tìm thấy tại đây, với một số điểm nổi bật được mô tả dưới đây.

Connection, KeepAlive, Close

Các headers này kiểm soát cách kết nối TCP được quản lý và bị xóa để tránh ảnh hưởng đến kết nối ở phía bên kia của proxy.

Transfer-Encoding

Header này mô tả định dạng của request hoặc response body trên đường truyền, ví dụ: 'chunked', và bị xóa vì định dạng có thể khác nhau giữa kết nối nội bộ và bên ngoài. Các HTTP stack đến và đi sẽ thêm transport headers khi cần.

TE

Chỉ giá trị header TE: trailers được phép qua proxy vì nó được yêu cầu cho một số triển khai gRPC.

Upgrade

Header này được sử dụng cho các giao thức như WebSockets. Nó bị xóa theo mặc định và chỉ được thêm lại cho các giao thức được hỗ trợ cụ thể (WebSockets, SPDY).

Proxy-*

Đây là các headers được sử dụng với các proxy và không được coi là phù hợp để chuyển tiếp.

Alt-Svc

Response header này được sử dụng với các nâng cấp HTTP/3 và chỉ áp dụng cho kết nối trực tiếp.

Distributed tracing headers (Headers theo dõi phân tán)

Các headers này bao gồm TraceParent, Request-Id, TraceState, Baggage, và Correlation-Context.

Chúng được tự động xóa dựa trên DistributedContextPropagator.Fields, cho phép HttpClient chuyển tiếp thay thế chúng bằng các giá trị được cập nhật.

Bạn có thể chọn không sửa đổi các headers này bằng cách đặt SocketsHttpHandler.ActivityHeadersPropagator thành null:

services.AddReverseProxy()
    .ConfigureHttpClient((_, handler) => handler.ActivityHeadersPropagator = null);

Strict-Transport-Security

Header này hướng dẫn clients luôn sử dụng HTTPS, nhưng có thể có xung đột giữa các giá trị được cung cấp bởi proxy và destination. Để tránh nhầm lẫn, giá trị của destination không được sao chép vào response nếu đã có một giá trị được thêm vào response bởi ứng dụng proxy.

Hướng dẫn cho các header khác

Host

Header Host chỉ ra trang web nào trên server mà request được dành cho. Header này bị xóa theo mặc định vì tên host được sử dụng công khai bởi proxy có thể khác với tên được sử dụng bởi dịch vụ phía sau proxy. Điều này có thể được cấu hình bằng cách sử dụng transform RequestHeaderOriginalHost.

X-Forwarded-*, Forwarded

Vì một kết nối riêng biệt được sử dụng để giao tiếp với destination, các request headers này có thể được sử dụng để chuyển tiếp thông tin về kết nối gốc, chẳng hạn như IP, scheme, port, và client certificate. X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, và X-Forwarded-Prefix được bật theo mặc định. Thông tin này dễ bị tấn công giả mạo nên mọi headers hiện có trong request đều bị xóa và thay thế theo mặc định. Ứng dụng destination nên cẩn thận về mức độ tin tưởng vào các giá trị này. Xem transforms để cấu hình chúng trong proxy. Để được hướng dẫn về cấu hình ứng dụng destination để đọc các headers này, xem Cấu hình ASP.NET Core để làm việc với proxy servers và load balancers.

X-http-method-override, x-http-method, x-method-override

Một số clients và servers giới hạn các HTTP method mà chúng cho phép (ví dụ: GET). Các request headers này đôi khi được sử dụng để giải quyết các hạn chế đó. Các headers này được proxy theo mặc định. Nếu trong proxy bạn muốn ngăn chặn các bỏ qua này thì hãy sử dụng transform RequestHeaderRemove.

Set-Cookie

Response header này có thể chứa các trường hạn chế các khía cạnh của URL, chẳng hạn như scheme, domain, hoặc path, nơi cookie nên được sử dụng. Sử dụng reverse proxy có thể thay đổi scheme, domain, hoặc path hiệu quả của một trang web từ góc nhìn công khai. Mặc dù có thể viết lại các response cookies bằng custom transforms, chúng tôi khuyến nghị thay vào đó sử dụng các Forwarded headers được mô tả trước đó để truyền các giá trị chính xác đến ứng dụng destination để nó có thể tạo ra các set-cookie headers chính xác.

Location

Response header này được sử dụng với các chuyển hướng và có thể chứa scheme, domain, và path khác với các giá trị công khai do sử dụng proxy. Mặc dù có thể viết lại header Location bằng custom transforms, nhưng khuyến nghị thay vào đó sử dụng các Forwarded headers được mô tả ở trên để truyền các giá trị chính xác đến ứng dụng destination để nó có thể tạo ra các header Location chính xác.

Server

Response header này chỉ ra công nghệ server nào được sử dụng để tạo ra response (ví dụ: IIS, Kestrel). Header này được proxy từ destination theo mặc định. Các ứng dụng muốn xóa nó có thể sử dụng transform ResponseHeaderRemove, trong trường hợp đó server header mặc định của proxy sẽ được sử dụng. Việc chặn server header mặc định của proxy là đặc thù của server, chẳng hạn như đối với Kestrel.

X-Powered-By

Response header này chỉ ra web framework nào được sử dụng để tạo ra response (ví dụ: ASP.NET). ASP.NET Core không tạo ra header này nhưng IIS có thể. Header này được proxy từ destination theo mặc định. Các ứng dụng muốn xóa nó có thể sử dụng transform ResponseHeaderRemove.