7 min to read
HTTP status code
The status codes
The status codes are all three-digit numbers that are grouped by the first digit into 5 groups. The reason phrases given with the status codes below are just suggestions. Server can return any reason phrase they wish.
1xx: Informational
No 1xx status codes are defined, and they are reserved for experimental purposes only.
2xx: Successful
Means that the request was processed successfully.
200 OK
Means that the server did whatever the client wanted it to, and all is well. Others The rest of the 2xx status codes are mainly meant for script processing and are not often used.
3xx: Redirection
Means that the resource is somewhere else and that the client should try again at a new address.
301 Moved permanently
The resource the client requested is somewhere else, and the client should go there to get it. Any links or other references to this resource should be updated.
302 Moved temporarily
This means the same as the 301 response, but links should now not be updated, since the resource may be moved again in the future.
304 Not modified
This response can be returned if the client used the if-modified-since header field and the resource has not been modified since the given time. Simply means that the cached version should be displayed for the user.
4xx: Client error
Means that the client screwed up somehow, usually by asking for something it should not have asked for.
400: Bad request
The request sent by the client didn’t have the correct syntax.
401: Unauthorized
Means that the client is not allowed to access the resource. This may change if the client retries with an authorization header.
403: Forbidden
The client is not allowed to access the resource and authorization will not help.
404: Not found
Seen this one before? :) It means that the server has not heard of the resource and has no further clues as to what the client should do about it. In other words: dead link. 5xx: Server error This means that the server screwed up or that it couldn’t do as the client requested.
500: Internal server error
Something went wrong inside the server.
501: Not implemented
The request method is not supported by the server.
503: Service unavailable
This sometimes happens if the server is too heavily loaded and cannot service the request. Usually, the solution is for the client to wait a while and try again.
The response header fields
These are the header fields a server can return in response to a request.
Location
This tells the user agent where the resource it requested can be found. The value is just the URL of the new resource.
Server
This tells the user agent which web server is used. Nearly all web servers return this header, although some leave it out.
Content-length
This gives the size of the resource, in bytes.
Content-type
This describes the file format of the resource.
Content-encoding
This means that the resource has been coded in some way and must be decoded before use.
Expires
This field can be set for data that are updated at a known time (for instance if they are generated by a script). It is used to prevent browsers from caching the resource beyond the given date.
Last-modified
This tells the browser when the resource was last modified. Can be useful for mirroring, update notification etc.
Caching: agents between the server and client
The browser cache
페이지로 돌아갈 때 페이지가 훨씬 빨리로드되기 전에 너무 오래 보지 않았다는 것을 알았을 것입니다. 브라우저가 처음 다운로드되었을 때 로컬 사본을 저장했기 때문입니다. 이 로컬 사본은 캐시라고합니다. 일반적으로 캐시의 최대 크기와 문서의 최대 캐싱 시간을 설정합니다.
즉, 새 페이지를 방문하면 캐시에 저장되며 캐시가 가득 찬 경우 (최대 크기 제한 근처) 브라우저가 다시 방문하지 않을 것으로 예상되는 일부 문서가 삭제되어 공간을 확보합니다. 또한 캐시에 저장된 페이지로 이동하면 브라우저에서 최대 저장 시간으로 7 일을 설정했으며 마지막 방문 이후 8 일이 지났음을 알 수 있으므로 페이지를 다시로드해야합니다.
캐시의 작동 방식은 브라우저마다 다르지만 이것이 기본 개념이며 사용자와 네트워크 트래픽의 시간을 모두 절약하므로 좋은 방법입니다. 관련된 HTTP 세부 사항도 있지만 나중에 다룰 것입니다.
Proxy caches
브라우저 캐시는 훌륭한 기능이지만 많은 사용자가 동일한 사이트를 탐색 할 때 일반적으로 동일한 문서를 여러 다른 캐시에 저장하고 다른 용도로 사용하기 위해 반복해서 새로 고칩니다. 분명히 이것은 최적이 아닙니다.
해결 방법은 사용자가 캐시를 공유하도록하는 것입니다. 이것이 바로 프록시 캐시와 관련된 것입니다. 브라우저에는 여전히 로컬 캐시가 있지만 브라우저 캐시에없는 문서에 대한 HTTP 요청은 더 이상 서버로 전송되지 않고 프록시 캐시로 전송됩니다. 프록시에 문서가 캐시에 있으면 브라우저 캐시처럼 문서를 반환하고 브라우저를 대신하여 요청을 제출하지 않으면 결과를 저장하고 브라우저에 릴레이합니다.
따라서 프록시는 실제로 여러 사용자에게 공통된 캐시이며 네트워크 트래픽을 상당히 줄일 수 있습니다. 또한 로그 기반 통계를 심하게 왜곡시킬 수 있습니다. :)
단일 프록시 캐시보다 고급 솔루션은 프록시 캐시 계층입니다. 대형 ISP가 국가의 각 부분에 대해 하나의 프록시 캐시를 가지고 있고 각 지역 프록시가 소스 웹 서버로 직접 이동하는 대신 국가 프록시 캐시를 사용하도록 설정했다고 가정하십시오. 이 솔루션은 네트워크 트래픽을 더욱 줄일 수 있습니다. 이에 대한 자세한 내용은 참고 문헌에 링크되어 있습니다.
CGI
CGI (Common Gateway Interface)는 웹 서버와 서버 측 프로그램이 상호 작용할 수있는 방법입니다. CGI는 프로그래밍 언어, 운영 체제 및 웹 서버와 완전히 독립적입니다. 현재 가장 일반적인 서버 측 프로그래밍 기술이며 존재하는 거의 모든 웹 서버에서도 지원됩니다. 또한 모든 서버는 거의 같은 방식으로 구현하므로 한 서버에 대해 CGI 스크립트를 작성한 다음 모든 웹 서버에서 실행되도록 배포 할 수 있습니다.
위에서 쓴 것처럼 서버는 어떤 URL이 스크립트에 매핑되고 어떤 URL이 일반 HTML 파일에 매핑되는지 알 수있는 방법이 필요합니다. CGI의 경우 이는 일반적으로 서버에서 CGI 디렉토리를 작성하여 수행됩니다. 이는 서버 설정에서 수행되며 특정 최상위 디렉토리의 모든 파일이 요청시 실행될 CGI 스크립트 (디스크 어딘가에 위치)임을 서버에 알려줍니다. (기본 디렉토리는 일반적으로 / cgi-bin /이므로 다음과 같은 URL을 알 수 있습니다. http://www.varsity.edu/cgi-bin/search CGI 스크립트를 가리 킵니다. 디렉토리는 무엇이든 호출 할 수 있습니다. .) 일부 서버는 CGI 디렉토리를 사용하지 않도록 설정하고 대신 모든 CGI 프로그램의 파일 이름이 .cgi로 끝나도록 요구할 수 있습니다.
CGI 프로그램은 일반적인 실행 프로그램 (또는 서버가 프로그램을 시작하는 방법을 알고있는 한 Perl 또는 Python으로 작성된 해석 된 프로그램) 일 뿐이므로 원하는 모든 프로그래밍 언어를 사용할 수 있습니다. CGI 프로그램이 시작되기 전에 웹 서버는 웹 서버가 요청에서 수신 한 정보를 포함하는 여러 환경 변수를 설정합니다. 이것의 예로는 클라이언트의 IP 주소, 요청의 헤더 등이 있습니다. 또한 요청 된 URL에?가 포함 된 경우? 환경 변수 자체에 저장됩니다.
즉, 요청에 대한 추가 정보를 링크의 URL에 넣을 수 있습니다. 이것이 자주 사용되는 한 가지 방법은 다중 사용자 적중 카운터에서 이번에 어떤 사용자가 적중했는지를 알리는 것입니다. 따라서 사용자는 자신의 페이지에 이미지를 삽입하고 SRC 속성이 다음과 같이 CGI 스크립트에 대한 링크가되도록 할 수 있습니다. SRC = “http://stats.vendor.com/cgi-bin/counter.pl?username “. 그런 다음 스크립트는 어떤 사용자가 적중했는지 알려주고 올바른 수를 표시합니다. (즉, 바울이 아니라 베드로의 것)
CGI가 출력 (HTTP 헤더 및 HTML 문서)을 서버에 반환하는 방법은 매우 간단합니다. 표준 출력에 씁니다. 다시 말해, Perl 또는 Python 스크립트에서는 print 문만 사용하면됩니다. C에서는 printf 또는 이와 동등한 것을 사용하고 (C ++은 cout «를 사용) Java는 System.out.println을 사용합니다.
CGI에 대한 자세한 내용 은 참고 자료를 참조하십시오 .
Other techniques
CGI는 확실히 서버 측 프로그램을 만드는 유일한 방법은 아니며 비 효율성에 대해 많은 비판을 받았습니다. 이 마지막 클레임은 CGI 프로그램을 메모리에로드하고 요청 될 때마다 처음부터 다시 실행해야하기 때문에 약간의 가중치가 있습니다.
훨씬 빠른 대안은 서버 API 자체에 프로그래밍하는 것입니다. 즉, 본질적으로 서버 프로세스의 일부가되고 서버 에 의해 노출 된 API를 사용하는 프로그램을 만듭니다 . 이 기술의 문제점은 API는 물론 서버에 따라 다르며 C / C ++ (일반적인) 프로그래밍 오류를 사용하면 전체 서버가 충돌 할 수 있다는 것입니다.
서버 API 프로그래밍의 주요 장점은 요청이 도착하면 프로그램이 필요한 데이터와 함께 메모리에 이미로드되어 있기 때문에 훨씬 빠릅니다.
일부 서버는 충돌 방지 언어로 스크립팅을 허용합니다. 한 예는 tcl을 사용하는 AOLServer입니다. Apache와 같은 서버에 사용할 수있는 모듈도 있습니다.이 모듈을 사용하면 Perl 또는 Python에서 서버 API 프로그래밍을 수행 할 수있어 서버 오류를 일으키는 프로그래밍 오류의 위험을 효과적으로 제거 할 수 있습니다.
또한 다양한 웹 서버를위한 독점적이며 비 독점적 인 스크립팅 언어와 기술이 많이 있습니다. 가장 잘 알려진 것은 ASP, MetaHTML 및 PHP3입니다.
Authentication
사용자가 자신의 ID를 확인할 수없는 경우 특정 URL에 대한 액세스를 허용하지 않도록 서버를 설정할 수 있습니다. 이는 일반적으로 설정에서 지정된 사용자 이름 / 암호 조합으로 수행되지만 다른 방법도 있습니다.
이러한 페이지가 요청되면 서버는 일반적으로 위에서 언급 한대로 “401 인증되지 않음”상태 코드를 반환합니다. 그런 다음 브라우저는 일반적으로 사용자에게 제공하는 사용자 이름과 암호를 입력하라는 메시지를 표시합니다 (알려진 경우). 그런 다음 브라우저는 다시 시도합니다. 이번에는 사용자 이름과 비밀번호를 값으로 사용하여 “Authorization”헤더를 추가합니다.
서버에서이를 수락하면 일반 요청과 마찬가지로 리소스가 반환됩니다. 그렇지 않은 경우 서버는 다시 401 상태 코드로 응답합니다.
Comments