URL이 어떻게 작동하는지 조금 혼란스러워요. 예전에는 HTML 등을 배울 때 도메인 이름 뒤에 오는 것이 로드하려는 파일의 위치라는 것을 알았습니다(예: website.com/somefolder/somefile.html). 그리고 그것은 간단해서 이해할 수 있었습니다.
최근에 웹에 대해 더 많은 것을 배워야 했고 URL이 더 복잡하다는 것을 알게 되었습니다. 예를 들어:
- drupal 링크는 somewebsite.com/node/43과 같습니다.
- REST 요청은 somewebsite.com/books/32와 같습니다.
- 후에 '?' 몇 가지 매개변수를 전달할 수 있습니다
어떻게 작동하나요? 서버(또는 다른 것? 저는 초보자입니다)는 요청을 받았을 때 URL이 무엇을 의미하는지 어떻게 알 수 있습니까? 그것은 수:
- 자원의 위치
- 드루팔 뷰
- REST 요청
- 다른 것?
내 질문이 말이 되는지 모르겠습니다. 제가 혼란스러워하는 이유를 이해해 주시길 바랍니다.
답변1
어떻게 작동하나요?
서버가 결정합니다.
서버(또는 다른 것? 저는 초보자입니다)는 요청을 받았을 때 URL이 무엇을 의미하는지 어떻게 알 수 있습니까?
서버는 해당 구성에 의존합니다. Unix 기반 서버의 경우 이는 종종 "구성" 파일이라고 불리는 하나 이상의 텍스트 파일에 의해 처리됩니다. 서버를 설정할 때 이를 지정할 수 있습니다. 이를 지정하는 방법에 대한 자세한 내용은 사용하는 웹 서버 소프트웨어에 따라 다릅니다.
(인기 있는 웹 서버 및 CGI 패키지에 대한 튜토리얼이 많이 있는 경향이 있으므로 웹사이트 관리자가 이를 수행하는 방법을 모르는 경우 일반적으로 해당 사람은 예제/문서/튜토리얼을 읽기 시작합니다. 따라서 Apache와 같은 웹 서버에서는 Drupal 설정에 대한 정보를 찾을 수 있을 것입니다. 반면에 Drupal과 같은 것에 대한 정보를 검색하면 Apache를 다음과 같이 구성하는 방법에 대한 문서 섹션을 찾을 수 있을 것입니다. Drupal을 사용하면 사용 가능한 문서가 너무 많아서 웹 사이트 관리자는 일반적으로 사용하려는 소프트웨어 패키지에 대한 관련 세부 정보를 찾기 위해 너무 많은 어려움을 겪을 필요가 없습니다.
HTTP 1.1 클라이언트는 URL을 세 부분으로 분할하는 경향이 있습니다.
- 프로토콜(예: http/https)
- 사이트(예: example.com)
- 리소스(예: /somedir/file.htm)
이는 약간 지나치게 단순화된 것일 수 있습니다. 다음과 같은 일부 이전 URL이 허용됩니다.ftp://username@password:example.com/somedir/file최신 웹 브라우저에서는 이러한 지원을 제거하는 경향이 있지만, 예를 들어MS KB 8344389, 보안 문제로 인해(발생한 눈에 띄는 양의 남용 포함, 예:http://paypal.com/gibberish%40PhishingSite.example.com/gibberish%40을 @인 ASCII 64로 변환하여 paypal.com/gibberish의 사용자 이름을 사용하여 PhishingSite.example.com에 로그인하면 간단히 로그인을 허용하고 사람들에게 PayPal 비밀번호를 묻습니다. 사람들은 URL 시작 부분에서 paypal.com을 보고 이를 신뢰합니다.
물론, URL의 #과 같은 일부 "표준"은 웹 클라이언트가 인식하고 서버로 보내지 않는 것입니다. 대신 웹 클라이언트는 # 뒤의 텍스트를 이동할 앵커 텍스트로 처리합니다. 또한 %는 16진수 문자를 이스케이프하는 데 사용됩니다. 웹 클라이언트는 이를 이해하는 경향이 있습니다.
기타 세부사항은 서버에 달려 있습니다. 예를 들어, 많은 웹 서버에는? 매개변수 목록을 시작하고 &(또는 많은 세미콜론?)를 사용하여 매개변수 목록 내에서 매개변수를 분할합니다. 그러나 이는 많은 웹 서버에서 나타나는 일반적인 동작일 뿐입니다. 웹 서버가 이를 존중하도록 강제하는 HTTP 부분은 없습니다. 실제로 웹 서버는 웹 서버가 원하는 대로 이를 처리할 수 있으며 웹 클라이언트는 이에 대한 특별한 지원을 요구하지 않을 것입니다.
HTTP 서버를 설정해 본 적이 있다면 해당 구성의 일부가 요청된 리소스로 수행할 작업을 지정한다는 점을 이해하게 될 것입니다. 예를 들어 /로 전송된 모든 항목은 /cgi-bin/에 있는 프로그램을 실행하는 /cgi-bin/과 /scripts 아래의 모든 항목을 제외하고 로컬 하드 드라이브의 /srv/httpdocs/ 영역에서 파일을 로드한다고 말할 수 있습니다. / 그리고 .pl로 끝나는 것은 PERL 인터프리터에 의해 실행됩니다.
구체적인 세부 사항은 웹 서버의 구성에 따라 다르므로 웹 클라이언트에게 정적 페이지의 복사본이나 실행되는 프로그램의 출력을 받을 수 있는지 여부를 알려주는 보편적인 표준은 없습니다. 웹 클라이언트가 기대할 수 있는 모든 것은 웹 클라이언트가 리소스를 요청하면 웹 서버가 이에 응답한다는 것입니다.
답변2
웹 서버는 그렇지 않습니다.알다 이러한 의미는 무엇이든 – 모든 경우에 리소스 경로를 수신하고 웹 사이트의 기본 프로그램을 통해 이를 실행한 다음 결과 출력을 보냅니다. 물론 다른 프로그램은 주어진 경로에 따라 다른 작업을 수행합니다.
구성된 프로그램이 없으면 해당 이름의 파일을 찾아 직접 제공합니다. (PHP와 CGI는 종종 중간 어딘가에 있습니다. 웹 서버는 여전히 파일을 찾지만 해당 파일을 실행합니다.그 자체프로그램대로.)
따라서 이를 "Drupal 보기"로 만드는 유일한 방법은 Drupal 소프트웨어에 /node/43전달되도록 구성된 웹 서버입니다 . /node/<anything>웹페이지가 동적으로 생성되었더라도 여전히 리소스로 간주됩니다.
(물론 Drupal 자체는 경로가 /node/다음으로 시작하면 뷰 ID가 뒤따른다는 것을 알고 있습니다.)
REST 요청은 완전히 일반적인 리소스 요청이기도 합니다. 그들을 "RESTful"로 만드는 것은 단지 전체적인 스타일과 행동일 뿐입니다. (예를 들어, 스타일의 URL은 /book/345REST 이데올로기에 적합하지만 /api/get_book?id=345그렇지 않습니다.)