Hy vọng ai đó có thể giúp tôi hoặc chỉ cho tôi đúng hướng.Sửa đổi phản hồi HTML (Không phải tiêu đề)
Tôi đã được yêu cầu tìm hiểu cách làm Akamai (hoặc bất kỳ CDN nào khác hoặc NGINX) sửa đổi nội dung phản hồi thực tế.
Tại sao?
Tôi làm cho CDN thay đổi tất cả các yêu cầu "http: //" thành "https: //" thay vì sửa đổi mã ứng dụng để sử dụng "//" cho các yêu cầu tài nguyên bên ngoài.
Điều này có khả thi không?
Có ai biết không?
này dường như là thể qua một số phương pháp khác nhau, nhưng đó không phải để nói như thế nào nên nó thực sự có thể.
Có vẻ như có khả năng có vấn đề (ví dụ: nếu bạn viết lại thứ gì đó không nên viết lại?) Và tài nguyên máy chuyên sâu (nhiều chu kỳ CPU để phân tích cú pháp và munge phản ứng liên tục).
Đây là những gì tôi thấy:
Nginx có http_sub_module xuất hiện để thực hiện điều này một cách khá đơn giản, giả sử những gì bạn muốn thay thế là đơn giản và bạn chỉ cần phù hợp với một mô hình trên mỗi trang, như thay thế <a href="http://example.com/... với <a href="https://example.com/..., một hoặc nhiều lần. Loại nội dung-mungery này có vẻ sơ sài nhưng tùy thuộc vào tình huống bạn đang ở (có thể là một trong những điều khiển giới hạn của ứng dụng) nó có thể đưa bạn đến đó.
Có vẻ như có một cái gì đó gọi là http_substitutions_filter, có thể không chính thức hoặc ít nhất không phải là một phần của phân phối Nginx lõi có thể viết lại dựa trên bộ lọc mạnh mẽ hơn.
Varnish seems to have khả năng tương tự (có thể là plugin) nhưng HAProxy doesn't, vì nó chỉ đề cập đến tiêu đề và để lại thân thể ngoại trừ khi thực hiện tải xuống gzip. Các phần mềm có khả năng đảo ngược proxy khác như Apache hoặc Squid cũng có thể cung cấp một cái gì đó hữu ích, mà bạn muốn đặt trước máy chủ ứng dụng của mình. Ấn tượng ban đầu của tôi, trong mọi trường hợp, là chuỗi thay thế đơn giản có thể không hoàn toàn giúp bạn ở đó, và thậm chí thay thế dựa trên regex cũng không thực sự đủ, mà không có sự tinh tế đáng kể trong regexes, bởi vì bạn luôn luôn có nguy cơ viết lại một cái gì đó mà bạn không nên.
Điều tôi đề nghị "thực sự cần phải xảy ra" để thực hiện mục đích này theo cách chính xác nhất, sẽ thực sự giải thích HTML được tạo bằng thư viện phân tích cú pháp DOM, duyệt cây và sửa đổi các yếu tố có liên quan - nơi, trước khi trao tài liệu sửa đổi cho người yêu cầu. Bằng cách này, tài liệu được sửa đổi dựa trên sự hiểu biết theo ngữ cảnh về nội dung của nó.
Nghe có vẻ phức tạp, theo ý kiến của tôi, vì nó là - vì vậy tôi sẽ đề nghị bạn xem xét lại cách tiếp cận đã lên kế hoạch của bạn trừ khi điều này nằm ngoài tầm kiểm soát của bạn.
Cuối cùng nghĩ: tò mò là tốt nhất của tôi, vì vậy tôi lấy câu hỏi này và trang bị thêm proxy ngược http tôi đã viết (cho một mục đích khác) để dựa trên kiểu nội dung, nó thực sự có thể phân tích cú pháp và đi bộ Cấu trúc HTML như một thực thể thích hợp, sửa đổi nó tại chỗ (như mô tả ở trên), trước khi trả về phần thân phản hồi cho người yêu cầu.
Điều này hóa ra, như tôi mong đợi, phải xử lý khá nhiều. Nội dung thử nghiệm của tôi là 29K HTML thực tế từ một trang web trực tiếp, có chứa 56 <a href ...> và 6 <link rel ...> yếu tố và thao tác ghi lại yêu cầu 128 mili giây trên Opteron 12 GHz và 43 MHz Xeon E5620 2,4 GHz. Những tiêu chuẩn này là đúng cho các hoạt động bổ sung - không bao gồm thời gian (số lượng nhỏ hơn) cần thiết cho chính chức năng "proxy" thực tế. Chi phí thời gian này không phải là không thể vượt qua, nhưng có thể thêm đến rất nhiều thời gian CPU. Điều này dài hơn nhiều so với viết lại nội dung dựa trên cụm từ thông thường, nhưng nó chính xác hơn nhiều và khó có thể phá vỡ các trang mà nó chạm vào.
HttpSubsModule Nginx của làm việc tuyệt vời cho tôi: http://wiki.nginx.org/HttpSubsModule
Thay đổi từ http đến https nên cũng đơn giản như thế này:
location/{
subs_filter_types text/html text/css text/xml;
subs_filter http.example.com https.example.com gi;
}
Chỉ cần giống nhau, nhưng đúng cú pháp.
location/{
sub_filter_types text/html text/css text/xml;
sub_filter 'http.example.com' 'https.example.com';
}