Các biến môi trường HTTP_PROXY, HTTPS_PROXY và NO_PROXY có chuẩn không?

Có vẻ như rất nhiều chương trình được thiết kế để đọc các biến môi trường này để quyết định proxy nào sẽ trải qua để kết nối với tài nguyên trên internet. Các chương trình đó cũng có thể có các cài đặt proxy riêng, riêng, nhưng nếu các cài đặt đó không được đặt, chúng sẽ vui vẻ sử dụng các biến môi trường này ...

• HTTP PROXY
• HTTPS_PROXY
• KHÔNG CÓ PROXY

Tôi chỉ muốn biết:

• Là những biến môi trường tiêu chuẩn?
• Có một đặc điểm kỹ thuật bằng văn bản (có thể do các nhà sản xuất hệ điều hành không?) Đề xuất sử dụng các biến môi trường này?

Tôi đồng ý với tuyên bố của BillThor rằng Đây là một quy ước hơn là một tiêu chuẩn.
Tôi không biết nguồn gốc của các biến này nhưng trong trường hợp HTTP trên * nix, nhiều quy ước dường như bắt nguồn từ hành vi của thư viện HTTP libcurl và chương trình dòng lệnh curl.

Tại https://curl.haxx.se/docs/manual.html có mô tả về các biến môi trường liên quan đến việc sử dụng proxy HTTP mà libcurl / curl hiểu:

BIẾN MÔI TRƯỜNG

Curl đọc và hiểu các biến môi trường sau:
http_proxy, HTTPS_PROXY, FTP_PROXY

Chúng nên được đặt cho các proxy dành riêng cho giao thức. Proxy chung nên được đặt với
ALL_PROXY

Một danh sách tên máy chủ được phân tách bằng dấu phẩy không nên đi qua bất kỳ proxy nào được đặt trong (chỉ dấu hoa thị, '*' khớp với tất cả máy chủ)
NO_PROXY

Nếu tên máy chủ khớp với một trong các chuỗi này hoặc máy chủ nằm trong miền của một trong các chuỗi này, các giao dịch với nút đó sẽ không được ủy quyền.

Xin lưu ý rằng http_proxychữ thường được viết là chữ duy nhất trong số các biến này. Một số thư viện / chương trình tìm kiếm tên viết thường của các biến này trong khi các thư viện khác tìm tên upppercase. Để an toàn, người ta phải xác định cả phiên bản chữ thường và chữ hoa của mỗi biến.

Một vấn đề khác là mô tả được trích dẫn về cách kết hợp tên máy chủ NO_PROXYkhông chính xác và không trả lời các câu hỏi sau:

• Các giá trị có nên là tên miền đủ điều kiện (FQDN) do đó kết thúc bằng dấu chấm như thế foo.example.com.hay không?
• Chỉ nên foo.example.comkhớp với một tên miền này hay nó cũng phù hợp với bất kỳ tên miền phụ nào bar.foo.example.com? Nếu sau này nó cũng nên phù hợp với bất kỳ tên miền phụ trong bất kỳ tên miền phụ như thế bar.baz.foo.example.comnào?
• Được .foo.example.com(chấm ở đầu) được cho phép và nếu vậy thì nó phải phù hợp với cái gì?
• Dấu hoa thị ( *) có được phép là một phần của giá trị ( *.example.com, *example.com) không và nếu có thì nó được xử lý như thế nào?

Thiếu đặc điểm kỹ thuật chính thức dẫn đến nhầm lẫn và lỗi. Ở đây người ta phải đề cập đến thư viện libproxy nhằm mục đích cung cấp hỗ trợ chính xác và nhất quán cho cấu hình proxy. Từ trang chủ của dự án :

libproxy tồn tại để trả lời câu hỏi: Với một tài nguyên mạng, làm thế nào để tôi tiếp cận nó? Nó xử lý tất cả các chi tiết, cho phép bạn quay lại lập trình.

Đọc thêm:

• Vấn đề tôi nêu ra đối với curl - Vui lòng ghi lại cú pháp và ngữ nghĩa của biến môi trường NO_PROXY.
• Vấn đề của Python - urllib: no_proxy các giá trị biến có dấu chấm hàng đầu không được xử lý đúng cách và câu hỏi SO liên quan - Python 2.7.13 không tôn trọng NO_PROXY và khiến lỗi urllib2.urlopen () với kết nối Đường hầm bị lỗi: 403 Bị cấm

Đây là một quy ước hơn là một tiêu chuẩn. Nó có thể được hỗ trợ bởi một hoặc nhiều thư viện xử lý giao thức thực sự tạo ra các kết nối. Java sử dụng các thuộc tính tương tự trong các thư viện giao thức của nó.

Hiểu và sử dụng các quy ước chung làm cho sự phát triển đơn giản hơn nhiều. Nó cũng giúp thực hiện nguyên tắc ít gây bất ngờ nhất và làm cho các chương trình có nhiều khả năng hơn just work.