URL là công cụ định vị tài nguyên hoặc một cái gì đó khác - nó hoạt động như thế nào?


0

Tôi hơi bối rối về cách URL hoạt động. Vào thời xưa, khi tôi đang học HTML và các công cụ, tôi biết rằng những gì diễn ra sau tên miền là vị trí của một tệp mà chúng tôi muốn tải (ví dụ: website.com/somefolder/somefile.html). Và nó thật đơn giản, tôi có thể hiểu nó.

Gần đây tôi đã phải tìm hiểu thêm một số điều về web và tôi thấy rằng các URL phức tạp hơn. Ví dụ:

  • các liên kết drupal giống như một cái gì đó
  • Các yêu cầu REST giống như một cái gì đó
  • sau '?' bạn có thể vượt qua một số tham số

Làm thế nào mà làm việc? Làm thế nào để máy chủ (hoặc một cái gì đó khác? Tôi khá mới làm quen) biết URL có nghĩa là gì khi nhận được yêu cầu? Nó có thể là:

  • vị trí của tài nguyên
  • xem drupal
  • Yêu cầu REST
  • một số thứ khác?

Tôi không biết nếu câu hỏi của tôi có ý nghĩa, tôi hy vọng bạn hiểu sự nhầm lẫn của tôi là gì.

Câu trả lời:


0

Làm thế nào mà làm việc?

Máy chủ quyết định.

Làm thế nào để máy chủ (hoặc một cái gì đó khác? Tôi khá mới làm quen) biết URL có nghĩa là gì khi nhận được yêu cầu?

Các máy chủ dựa trên cấu hình của nó. Đối với các máy chủ dựa trên Unix, điều này thường được xử lý bởi một hoặc nhiều tệp văn bản thường được gọi là tệp "cấu hình". Khi thiết lập máy chủ, bạn có thể chỉ định điều này. Chi tiết về cách chỉ định điều này sẽ thay đổi dựa trên phần mềm máy chủ web bạn sử dụng.

(Có xu hướng có nhiều hướng dẫn cho các máy chủ web và gói CGI phổ biến, vì vậy nếu quản trị viên trang web không biết cách thực hiện, người đó thường bắt đầu đọc các ví dụ / tài liệu / hướng dẫn. Vì vậy, nếu bạn tìm tài liệu về Máy chủ web như Apache, bạn có thể tìm thấy thông tin về việc thiết lập Drupal. Mặt khác, nếu bạn tìm kiếm thông tin cho một cái gì đó như Drupal, bạn có thể sẽ tìm thấy một phần tài liệu về cách định cấu hình Apache để sử dụng Drupal. Với rất nhiều tài liệu có sẵn, quản trị viên trang web thường không cần phải vật lộn quá nhiều để tìm chi tiết có liên quan cho các gói phần mềm họ muốn sử dụng.)

Máy khách HTTP 1.1 có xu hướng chia URL thành 3 phần:

  • Giao thức (ví dụ: http / https)
  • Trang web (ví dụ example.com)
  • tài nguyên (ví dụ /somedir/file.htm)

Đó có thể là một sự đơn giản hóa một chút. Một số URL cũ hơn được phép cho một cái gì đó như ftp: // username @ password: example.com/somedir/file mặc dù các trình duyệt web mới hơn có xu hướng xóa hỗ trợ đó, ví dụ: MS KB 8344389 , vì lo ngại về bảo mật (bao gồm cả mức độ lạm dụng đáng chú ý đã xảy ra, ví dụ: http://paypal.com/gibberish%40PhishingSite.example.com/gibberish sẽ chuyển đổi% 40 thành ASCII 64 là @, khiến tên người dùng của paypal.com/gibberish được sử dụng để đăng nhập vào PhishingSite .example.com sẽ đơn giản chấp nhận đăng nhập và hỏi mọi người mật khẩu PayPal của họ. Mọi người sẽ thấy paypal.com khi bắt đầu URL và tin tưởng vào nó.

Chắc chắn, có một số "tiêu chuẩn" như # trong một URL là thứ mà máy khách web sẽ nhận ra và sẽ không gửi nó đến máy chủ. Thay vào đó, máy khách web sẽ coi văn bản sau # là văn bản neo để chuyển đến. Ngoài ra,% được sử dụng để thoát các ký tự hex. Khách hàng web có xu hướng hiểu điều đó.

Các chi tiết khác có thể lên đến máy chủ. Ví dụ, nhiều máy chủ web có? bắt đầu một danh sách các tham số và sử dụng & (hoặc nhiều dấu chấm phẩy?) để phân tách các tham số trong danh sách các tham số. Tuy nhiên, đó chỉ đơn giản là hành vi phổ biến được thể hiện bởi nhiều máy chủ web. Không có phần HTTP nào buộc các máy chủ web tôn vinh điều đó. Thực sự, máy chủ web có thể xử lý điều đó tuy nhiên máy chủ web muốn và máy khách web có thể không yêu cầu bất kỳ sự hỗ trợ đặc biệt nào cho việc đó.

Nếu bạn đã từng thiết lập máy chủ HTTP, có thể bạn sẽ hiểu rằng một phần của cấu hình đó đang chỉ định những việc cần làm với các tài nguyên được yêu cầu. ví dụ: bạn có thể nói rằng mọi thứ được gửi tới / sẽ tải các tệp từ / srv / httpdocs / của ổ cứng cục bộ, ngoại trừ / cgi-bin / sẽ chạy chương trình nằm trong / cgi-bin / và bất cứ thứ gì dưới / script / và kết thúc bằng .pl sẽ được chạy bởi trình thông dịch PERL.

Các chi tiết cụ thể khác nhau dựa trên cấu hình của máy chủ web, do đó, không có một tiêu chuẩn chung nào sẽ cho khách hàng biết liệu nó có thể được đảm bảo để nhận một bản sao của trang tĩnh hay đầu ra của chương trình được chạy hay không. Tất cả các máy khách web có thể mong đợi là nếu máy khách web yêu cầu tài nguyên, máy chủ web sẽ trả lời nó.


0

Máy chủ web không biết bất kỳ ý nghĩa nào - trong mọi trường hợp, nó chỉ nhận được đường dẫn tài nguyên, chạy nó thông qua chương trình chính của trang web và gửi cho bạn kết quả đầu ra. Và tất nhiên các chương trình khác nhau làm những việc khác nhau với con đường họ đã được đưa ra.

Nếu không có chương trình được cấu hình, nó sẽ tìm một tệp có tên đó và phục vụ trực tiếp. (PHP và CGI thường ở đâu đó ở giữa: máy chủ web vẫn tìm tệp, nhưng sau đó tự chạy tệp đó dưới dạng chương trình.)

Vì vậy, điều duy nhất /node/43khiến nó trở thành "Chế độ xem Drupal" là máy chủ web đã được cấu hình để chuyển /node/<anything>sang phần mềm Drupal. Trang web vẫn được coi là một tài nguyên, mặc dù nó đã được tạo động.

(Tất nhiên, chính Drupal biết rằng nếu đường dẫn bắt đầu bằng /node/nó sẽ được theo sau bởi ID xem.)

Yêu cầu REST cũng là yêu cầu tài nguyên hoàn toàn thường xuyên; những gì làm cho họ "RESTful" chỉ là phong cách và hành vi tổng thể. (Ví dụ: các URL theo kiểu /book/345phù hợp với ý thức hệ REST, trong khi /api/get_book?id=345thì không.)

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.