Bài 2

reverse_proxy và tiền tố đường dẫn

Trong nginx, một dấu gạch chéo trong proxy_pass quyết định backend nhận đường dẫn nào. Caddy bỏ hẳn cơ chế đó: reverse_proxy gửi nguyên request URI, và muốn cắt tiền tố thì phải viết ra bằng một chỉ thị riêng. Bài này đo bảy tổ hợp, trong đó hai tổ hợp không trả về 200.

Caddy không cắt gì cả

Mặc định reverse_proxy chuyển tiếp nguyên request URI. Có hai cách yêu cầu cắt tiền tố, và chúng cắt khác nhau:

• handle_path /b/* — cắt tiền tố của chính mẫu đó. Tiền tố bị cắt là mẫu sau khi bỏ * ở cuối rồi bỏ nốt dấu / cuối, nên /b/* cắt /b chứ không phải /b/.
• uri strip_prefix /c — cắt đúng chuỗi bạn viết, không thêm bớt gì. Nó độc lập với mẫu của handle, nên có thể cắt nhầm hoặc không cắt gì.

Ngoài ra rewrite * <mẫu> thay hẳn đường dẫn, với {uri} là giá trị ngay trước bước đó — nên đặt rewrite trong một khối handle_path sẽ thấy phần đã cắt, còn đặt trong handle thì thấy đường dẫn nguyên.

Bảy tổ hợp, đo trên Caddy thật

Bộ đo gồm hai server trong cùng một container caddy:2-alpine. Server ở cổng 8081 đóng vai backend và in lại đúng {http.request.uri} mà nó nhận.

:8081 {
	handle {
		respond "{http.request.uri}" 200
	}
}

:80 {
	handle /a/* {
		reverse_proxy localhost:8081
	}
	handle_path /b/* {
		reverse_proxy localhost:8081
	}
	handle /c/* {
		uri strip_prefix /c
		reverse_proxy localhost:8081
	}
	handle /d/* {
		rewrite * /goc{uri}
		reverse_proxy localhost:8081
	}
	handle_path /e/* {
		rewrite * /goc{uri}
		reverse_proxy localhost:8081
	}
}

Hai dòng cuối cho thấy hai chi tiết nhỏ: handle_path cắt được tiền tố nhiều tầng, và khi cắt hết sạch thì Caddy đặt lại đường dẫn thành / chứ không để rỗng.

Dòng thứ tư và thứ năm là cặp đáng so nhất. Cùng một rewrite * /goc{uri}, đặt trong handle cho ra /goc/d/x/y, đặt trong handle_path cho ra /goc/x/y. {uri} đọc giá trị tại thời điểm chạy, và handle_path đã cắt trước đó.

Mất dấu gạch chéo thì được 400

Hai cách viết dưới đây đều cắt quá tay một ký tự, và cả hai đều cho cùng một kết quả:

handle_path /g* { reverse_proxy … }   gọi /gx/y   → còn lại "x/y"
handle /h/* {                         gọi /h/x/y  → còn lại "x/y"
	uri strip_prefix /h/
	reverse_proxy …
}

Đây là chỗ Caddy và nginx phạt cùng một sơ suất theo hai cách. Với nginx, location /d/ cộng proxy_pass http://be:8080/goc cho ra /gocx/y — một đường dẫn hợp lệ nhưng sai, backend trả 404 và không ai biết vì sao. Với Caddy, request dừng ngay ở proxy với mã 400. Lỗi của Caddy dễ thấy hơn, nhưng khó lần ra nguồn hơn vì không có log.

Đường dẫn trong địa chỉ upstream thì được 502

Người quen nginx hay viết đường dẫn ngay trong địa chỉ backend. Caddy không hiểu cách viết đó, nhưng cũng không từ chối nó:

handle /f/* {
	reverse_proxy localhost:8081/goc
}

$ caddy validate --config /c --adapter caddyfile
Valid configuration

Server khởi động bình thường. Nhìn vào cấu hình JSON mới thấy vấn đề — phần đường dẫn bị ghép thẳng vào chuỗi quay số:

"upstreams": [ { "dial": "localhost:8081/goc:80" } ]

Mọi request qua khối đó trả về 502, và log ghi:

{"level":"error","logger":"http.log.error",
 "msg":"dial localhost:8081: unknown network localhost:8081",
 "status":502}

Phòng thí nghiệm

Đổi bất kỳ ô nào. Thuật toán chạy trên trình duyệt là bản viết lại quy tắc ở trên, đã đối chiếu với Caddy v2.11.4 trên đúng 13 tổ hợp — khớp 13/13, kể cả hai trường hợp 400 và 502.

Tự kiểm tra