많은 블로그 로그 읽기 페이지 끝에 영구 링크가 표시되며, 이 링크는 일반적으로 오래 지속됩니다. 블로그 프로그램이 변경되더라도 이 링크를 사용하면 찾을 수 없는 문제 없이 원본 로그에 액세스할 수 있습니다. 페이지 상황, 이것은 실제로 블로그에 대한 실용적인 기능입니다.
블로그 프로그램을 수정할 때도 이 문제를 고려하여 블로그 로그에 영구 링크 기능을 추가하기로 결정했습니다.
IIS6에서는 매개변수 다음에 디렉터리를 요청하면 이 매개변수가 기본 문서로 전달됩니다. 즉, 내 블로그 홈페이지 http://www.xujiwei.cn/blog/?id=500 을 요청하면 id=500은 기본 문서 default.asp로 전달됩니다. 이를 사용하여 블로그 로그에 대한 영구 링크를 얻을 수 있습니다. 물론, 이 영구 링크는 블로그 디렉토리가 변경되지 않을 때 설정됩니다. 디렉토리가 변경되면 추가 처리가 필요합니다.
Response.Redirect는 ASP에서 사용할 수 있습니다. 원칙적으로는 서버가 302 Object Moved 응답을 클라이언트에 보낸 다음 클라이언트가 응답을 기반으로 리디렉션을 수행하지만 이로 인해 추가 대역폭 오버헤드가 증가하고 검색을 사용하지 않습니다. 엔진에서 이를 포함하므로 리디렉션하려면 Server.Transfer를 사용하는 것이 좋습니다. Server.Transfer는 현재 스크립트의 실행을 직접 중지하고 대신 지정된 스크립트를 실행하며, 세션과 같은 일부 현재 변수는 매개변수를 다시 전달할 필요 없이 새 스크립트에서 직접 사용할 수 있는 반면, Response.Redirect는 그렇지 않습니다.
두 방법의 또 다른 명백한 차이점은 Response.Redirect를 사용할 때 클라이언트가 표시하는 URL이 변경되지만 Server.Transfer를 사용할 때는 변경되지 않는다는 것입니다. Server.Transfer를 사용할 때 클라이언트는 현재 URL이 실제로 변경되었다고 느끼지 않습니다. 실제로 이 차이점은 두 메서드의 호출 방식을 통해서도 알 수 있는데, 그 중 하나는 Response.Redirect가 클라이언트에 의해 변경되고 Server.Transfer가 서버에 의해 변경된다는 점입니다.
이러한 내용을 이해한 후에는 default.asp, index.asp 등과 같은 블로그 프로그램의 홈페이지인 블로그의 기본 문서를 열고 출력 콘텐츠 앞에 다음 코드를 추가할 수 있습니다.
<%IF Request.QueryString ("id") Then Server.Transfer("article.asp")%>
물론, article.asp는 블로그 프로그램에 맞게 변경되어야 합니다. id는 영구 링크로 사용하기 위한 매개변수입니다. 이 매개변수는 반드시 article.asp, 즉 기사로 인식되어야 한다는 점에 유의해야 합니다. asp는 이 매개변수를 기반으로 로그를 표시할 수 있습니다. 그렇지 않은 경우 해당 변경을 수행해야 합니다. 즉, article.asp의 매개변수 이름을 id로 변경하거나 id를 다른 이름으로 변경해야 합니다.
알았어, 끝났어! 사실, 이것은 매우 간단합니다. 그렇게 긴 기사는 대부분 말도 안 되는 내용이며, 실제로 유용한 유일한 것은 코드 문장입니다.