Dấu hai chấm `:` có an toàn cho việc sử dụng URL thân thiện không?


109

Chúng tôi đang thiết kế một hệ thống URL sẽ chỉ định các phần ứng dụng dưới dạng các từ được phân tách bằng dấu gạch chéo. Cụ thể, đây là trong GWT, vì vậy các phần liên quan của URL sẽ nằm trong hàm băm (sẽ được giải thích bởi một lớp bộ điều khiển ở phía máy khách):

http://site/gwturl#section1/section2

Một số phần có thể cần các thuộc tính bổ sung mà chúng tôi muốn chỉ định bằng a :, để các phần của URL rõ ràng. Đầu tiên /, mã sẽ phân tách , sau đó mới đến :, như thế này:

http://site/gwturl#user:45/comments

Tất nhiên, chúng tôi đang làm điều này để thân thiện với url, vì vậy chúng tôi muốn đảm bảo rằng không có ký tự nào trong số những ký tự có ý nghĩa đặc biệt này sẽ được mã hóa url bởi các trình duyệt hoặc bất kỳ hệ thống nào khác và kết thúc bằng một url như điều này:

http://site/gwturl#user%3A45/comments <--- BAD

Việc sử dụng dấu hai chấm theo cách này có an toàn không (theo ý tôi là sẽ không được mã hóa tự động) cho các trình duyệt, hệ thống đánh dấu trang, thậm chí cả mã Javascript hoặc Java?


Có lẽ bạn nên chỉ định (rõ ràng hơn) rằng bạn chỉ sử dụng các URL ở phía máy khách? Vì rất nhiều câu trả lời (cũng như của tôi) dường như cho rằng bạn sẽ gửi URL đến một máy chủ bằng HTTP.
Veger

Đã chỉnh sửa để làm rõ thêm rằng việc sử dụng phân đoạn đang diễn ra ở phía máy khách.
Nicole,

Tôi tò mò: sau 10 tháng, lược đồ url này có phù hợp với bạn không? Tôi đang xem xét sử dụng cùng một chương trình.
Jonathan Swinney

1
@Jonathan Swinney, Thật không may, tôi đã chuyển từ dự án này (và công ty), mặc dù các câu trả lời ở đây làm tôi hài lòng rằng đó là con đường để đi. Nếu tôi bắt đầu một dự án mới, tôi sẽ sử dụng lược đồ này, nhưng tôi cũng sẽ chắc chắn sử dụng #!để chỉ ra rằng các trang là trạng thái - xem googlewebmastercentral.blogspot.com/2009/10/… (Đề xuất này đã được tuân theo bởi người dùng AJAX nặng như Facebook)
Nicole

Tôi vừa phát hiện ra rằng WhatsApp sẽ cắt một URL trên dấu hai chấm đầu tiên, vì vậy, ví dụ như nó khiến URL bản đồ google trở nên vô dụng. Vì vậy, có, điều quan trọng là phải thoát khỏi nó.
Petruza

Câu trả lời:


83

Gần đây tôi đã viết một bộ mã hóa URL, vì vậy điều này khá mới mẻ trong tâm trí tôi.

http://site/gwturl#user:45/comments

Tất cả các ký tự trong phần đoạn ( user:45/comments) hoàn toàn hợp pháp đối với các URI RFC 3986 .

Các phần liên quan của ABNF :

fragment      = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Ngoài những hạn chế này, phần phân mảnh không có cấu trúc xác định nào ngoài cấu trúc mà ứng dụng của bạn cung cấp cho nó. Đề án, http, chỉ nói rằng bạn không gửi phần này đến máy chủ.


BIÊN TẬP:

Ôi!

Bất chấp những khẳng định của tôi về thông số kỹ thuật URI, không thể chối cãi cung cấp câu trả lời chính xác khi anh ấy chỉ ra rằng thông số kỹ thuật HTML 4 hạn chế tên phần tử / số nhận dạng .

Lưu ý rằng các quy tắc nhận dạng đang thay đổi trong HTML 5 . Các hạn chế của URI vẫn sẽ được áp dụng (tại thời điểm viết bài, có một số vấn đề chưa được giải quyết xung quanh việc sử dụng URI của HTML 5).


Tôi nghĩ rằng bạn đang trên một cái gì đó, bạn có thể giải thích điều này thêm một chút? Không gửi cái này đến máy chủ không phải là một vấn đề, vì chúng tôi đang sử dụng GWT. Tôi chỉ không chắc mình rõ ràng về cú pháp được chỉ định bởi phần bạn đã trích dẫn.
Nicole

Nhưng :là một gen-delim, không phải là một sub-delim.
bobince

1
Các dấu chấm phẩy là hợp pháp cho một pchar, vì vậy cho dù đó là trong tiểu dấu phân cách hoặc gen-dấu phân cách không phải là một vấn đề
Veger

@bobince - :ở trong pchar, ở trong fragment, :được phép. @Renesis - Wikipedia có một bài viết trên ABNF en.wikipedia.org/wiki/ABNF Về cơ bản, bạn đang xem danh sách các ký tự được phép, trong đó /có nghĩa là HOẶC . Tôi chưa thực hiện bất kỳ lập trình GWT nào, vì vậy tôi không biết nó sử dụng phần phân mảnh của URI như thế nào.
McDowell

Một câu hỏi cuối cùng - bạn có bất kỳ thông tin chi tiết nào về ứng dụng trong thế giới thực của đặc tả này không? Điều này có nghĩa là các trình duyệt nên / sẽ bỏ qua (bỏ qua mã hóa của) :trong phân đoạn?
Nicole

59

Ngoài phân tích của McDowell về tiêu chuẩn URI, hãy nhớ rằng phân đoạn phải là tên liên kết HTML hợp lệ. Theo http://www.w3.org/TR/html4/types.html#type-name

Mã thông báo ID và TÊN phải bắt đầu bằng một chữ cái ([A-Za-z]) và có thể được theo sau bởi bất kỳ số chữ cái, chữ số ([0-9]), dấu gạch ngang ("-"), dấu gạch dưới ("_") , dấu hai chấm (":") và dấu chấm (".").

Vì vậy, bạn là người may mắn. ":" được cho phép một cách rõ ràng. Và không ai nên "%" - thoát khỏi nó, không chỉ vì "%" là ký tự bất hợp pháp ở đó, mà còn bởi vì phân đoạn phải khớp với tên neo char-by-char, do đó không có tác nhân nào nên cố gắng giả mạo chúng theo bất kỳ cách nào.

Tuy nhiên bạn phải kiểm tra nó. Các tiêu chuẩn web không được tuân thủ nghiêm ngặt, đôi khi các tiêu chuẩn mâu thuẫn với nhau. Ví dụ: HTTP / 1.1 RFC 2616 không cho phép chuỗi truy vấn trong URL yêu cầu, trong khi HTML xây dựng một chuỗi khi gửi biểu mẫu với phương thức GET. Bên nào được triển khai trong thế giới thực sẽ thắng vào cuối ngày.


58

MediaWiki và các công cụ wiki khác sử dụng dấu hai chấm trong URL của họ để chỉ định không gian tên, dường như không có vấn đề gì lớn.

ví dụ: http://en.wikipedia.org/wiki/Template:Welcome


31
Câu trả lời phù hợp nhất. Tất cả chúng ta đều biết rằng những gì trong thông số kỹ thuật ít liên quan đến thực tế trong phát triển web. Bạn sẽ không nhận được sự đảm bảo "an toàn" tốt hơn nhiều so với "một trong 10 trang web hàng đầu thế giới làm được điều đó".
Steven Collins

1
@StevenCollins Không còn phù hợp hơn so với câu trả lời cho 3 năm trước với trang này rằng các quốc gia một cách chính xác những điều tương tự :)
Martin James

7

Tôi sẽ không tin tưởng vào nó. Nó có thể sẽ được mã hóa url %3Abởi nhiều tác nhân người dùng.


1
@arbales: Có. Một số tác nhân người dùng ít tuân thủ hơn sẽ để lại các url không tuân thủ không được tô điểm.
Asaph

4

Từ URLEncoderjavadoc:

Để biết thêm thông tin về mã hóa biểu mẫu HTML, hãy tham khảo thông số kỹ thuật HTML .

Khi mã hóa một chuỗi, các quy tắc sau được áp dụng:

  • Các ký tự chữ và số "a" đến "z", "A" đến "Z" và "0" đến "9" vẫn được giữ nguyên.
  • Các ký tự đặc biệt ".", "-", "*" và "_" vẫn được giữ nguyên.
  • Ký tự khoảng trắng "" được chuyển thành dấu cộng "+".
  • Tất cả các ký tự khác đều không an toàn và lần đầu tiên được chuyển đổi thành một hoặc nhiều byte bằng cách sử dụng một số lược đồ mã hóa. Sau đó, mỗi byte được biểu diễn bằng chuỗi 3 ký tự "% xy", trong đó xy là biểu diễn thập lục phân có hai chữ số của byte. Lược đồ mã hóa được khuyến nghị sử dụng là UTF-8. Tuy nhiên, vì lý do tương thích, nếu một mã hóa không được chỉ định, thì mã hóa mặc định của nền tảng sẽ được sử dụng.

Đó là, :không an toàn.


3

Tôi không thấy Firefox hoặc IE8 mã hóa một số URL Wikipedia bao gồm ký tự.


1
Opera cũng giữ dấu chấm phẩy, nhưng đếm trên hành vi như vậy không phải là một điều tốt để làm
Veger

1
Renesis đang nói về phân đoạn URL chứ không phải đường dẫn URL.
Gumbo

Wikipedia là một trong những suy nghĩ của tôi khi viết câu hỏi này. Việc sử dụng dấu hai chấm về mặt kỹ thuật có không hợp lệ / không an toàn không? Tôi thường thấy (và) trong các URL Wikipedia được mã hóa, nhưng không bao giờ thấy dấu hai chấm, điều này khiến tôi hơi bối rối.
Nicole

3
Máy Wayback có: trong nhiều liên kết của nó - ví dụ web.archive.org/web/20080822150704/http://stackoverflow.com
barrowc

2

Dấu hai chấm được sử dụng làm dấu phân tách giữa tên người dùng và mật khẩu nếu giao thức yêu cầu xác thực.


0

Colon không an toàn. Xem tại đây


Trang đó không thúc đẩy lý do tại sao họ không an toàn. RFC2396 được tham chiếu cũng không cho biết nó phải được thoát. Ngoài ra, tập lệnh chuyển đổi được cung cấp không mã hóa nó (dù sao trong Chrome 9).
Adam Lindberg

Adam bạn không chính xác. Nó trực tiếp nêu rõ điều gì và tại sao.
ktamlyn

-5

Nó không phải là một ký tự an toàn và được sử dụng để phân biệt cổng nào bạn kết nối khi nó nằm ngay sau tên miền của bạn

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.