IPv6 zones trong URL là một sai lầm thiết kế

IPv6 là một giao thức mạng đầy thú vị nhưng cũng chứa đựng những điểm kỳ quặc khiến các lập trình viên phải đau đầu. Một trong những khía cạnh lạ lùng nhất của tiêu chuẩn này là cách xử lý địa chỉ link-local (cục bộ) và sự va chạm không tránh khỏi của chúng với cấu trúc URL.

Vấn đề về địa chỉ Link-local trong IPv6

Mọi giao diện mạng trong IPv6 đều có địa chỉ link-local nằm trong dải fe80::. Nếu một máy chủ có hai giao diện mạng, cả hai đều sẽ có địa chỉ bắt đầu bằng fe80::. Vậy khi bạn gửi một gói tin đến fe80::4, hệ thống làm thế nào để biết gói tin đó đi qua card mạng nào?

Câu trả lời nằm ở IPv6 scopes/zones. Định dạng chính xác của zone phụ thuộc vào hệ điều hành: trên Linux, đó là tên giao diện (ví dụ: eth0), còn trên Windows, đó là ID của giao diện. Điều này giúp bảng định tuyến của kernel biết cách xử lý xung đột dải địa chỉ.

Trên máy tính của tôi, địa chỉ này sẽ được biểu diễn như sau:

fe80::4%eth0

Trong đó eth0 là tên thiết bị ethernet.

Xung đột với cú pháp URL

Thông thường, khi tạo một bindhost host:port, người ta dùng dấu hai chấm để phân tách. Tuy nhiên, IPv6 cũng dùng dấu hai chấm để phân tách các nhóm hex. Để phân biệt đâu là host, đâu là port, người ta thường đặt địa chỉ IPv6 trong dấu ngoặc vuông. Ví dụ, fe80::4 trên port 80 sẽ là:

[fe80::4]:80

Và khi thêm zone vào, nó trông như thế này:

[fe80::4%eth0]:80

Vấn đề nảy sinh khi chúng ta đưa chuỗi này vào một URL đầy đủ. Theo logic thông thường, URL sẽ là:

http://[fe80::4%eth0]:80

Tuy nhiên, nếu bạn cố gắng phân tích chuỗi này trong ngôn ngữ lập trình Go, bạn sẽ gặp lỗi ngay lập tức.

package main

import "net/url"

func main() {
    if _, err := url.Parse("http://[fe80::4%eth0]:80"); err != nil {
        panic(err)
    }
}

Kết quả là:

panic: parse "http://[fe80::4%eth0]:80": invalid URL escape "%et"

Tại sao lại xảy ra lỗi này?

Lỗi này xuất hiện do cơ chế URL encoding. URL không thể biểu diễn tất cả các giá trị Unicode, nên các ký tự không phù hợp với ngữ pháp của URL sẽ được mã hóa bằng phần trăm (percent-encoded). Đó là lý do đôi khi bạn thấy %20 trong URL; nó đại diện cho dấu cách (space).

Khi trình phân tích URL gặp %eth0, nó cố gắng giải mã %et như một chuỗi escape. Vì et không phải là một mã hex hợp lệ, Go báo lỗi.

Giải pháp: Mã hóa kép

Để khắc phục vấn đề này, bạn phải mã hóa chính dấu % trong zone IPv6. Dấu % sẽ trở thành %25.

package main

import (
    "fmt"
    "net/url"
)

func main() {
    u, err := url.Parse("http://[fe80::4%25eth0]:80")
    if err != nil {
        panic(err)
    }
    fmt.Println(u.Hostname())
}

Kết quả:

fe80::4%eth0

Về mặt lý thuyết, RFC 9844 đưa ra hướng dẫn về cách xử lý IPv6 zones trong giao diện người dùng, nhưng không có hướng dẫn cụ thể cho URL. Hành vi của Go thực tế lại tuân theo RFC 6874, quy định rằng:

IPv6addrz = IPv6address "%25" ZoneID

Điều này có nghĩa là việc sử dụng %25 là đúng chuẩn, dù nó trông có vẻ kỳ quặc và khó chịu.

Một vấn đề chung của ngành công nghiệp

Sự khó xử này không chỉ giới hạn ở Go. Nó là một trường hợp ngoại lệ (edge case) ảnh hưởng đến nhiều khung công việc, ngôn ngữ và thư viện khác:

• Nginx: Gặp vấn đề tương tự với việc xử lý các ký tự này.
• Python Requests: Cũng phải đối mặt với thách thức phân tích cú pháp này.
• Trình duyệt: Hiện tại không hỗ trợ IPv6 zones vì nó phá vỡ khái niệm "origin" (nguồn gốc), vốn được sử dụng cho nhiều cơ chế bảo mật và chức năng tinh tế khác. Một bản dự thảo RFC đang cố gắng định nghĩa một "zone origin" để các trình duyệt có cơ sở áp dụng.

Trong khi chờ đợi một giải pháp tốt hơn trong tương lai, chính sách không fork (sao chép sửa đổi) thư viện chuẩn của Go buộc tôi phải chấp nhận trải nghiệm người dùng tồi tệ này cho một trường hợp ngoại lệ hiếm gặp. Tôi ghét điều đó, nhưng trong thế giới lập trình, đôi khi chúng ta phải chọn giải pháp ít tồi tệ nhất.

Tóm lại, máy tính thực sự là một sai lầm—hoặc ít nhất là cách chúng ta thiết kế các tiêu chuẩn cho nó là như vậy.