많은 웹 개발자에게는 간단한 요청을 생성하고 간단한 응답을 받는 것만으로도 충분하지만 Ajax를 마스터하려는 개발자에게는 HTTP 상태 코드, 준비 상태 및 XMLHttpRequest 개체에 대한 완전한 이해가 필요합니다. 이 기사에서 Brett McLaughlin은 다양한 상태 코드를 소개하고 브라우저가 이를 처리하는 방법도 보여줍니다. 또한 Ajax에서 사용되는 덜 일반적인 HTTP 요청도 살펴봅니다.
이 시리즈의 이전 기사에서 우리는 Ajax 애플리케이션의 핵심이자 서버 측 애플리케이션 및 스크립트의 요청을 처리하고 서버 측 구성 요소에서 반환된 데이터를 처리하는 XMLHttpRequest 개체에 대해 자세히 살펴보았습니다. 모든 Ajax 애플리케이션은 XMLHttpRequest 객체를 사용하므로 Ajax가 더 나은 성능을 발휘할 수 있도록 이 객체에 익숙해지는 것이 좋습니다.
이 기사에서는 이전 기사를 기반으로 이 요청 개체의 세 가지 주요 부분에 중점을 둘 것입니다.
· HTTP 준비 상태 · HTTP 상태 코드 · 생성할 수 있는 요청 유형
이 세 부분은 모두 고려해야 할 요소를 구성하는 데 있습니다
.그러나 요청할 때 이러한 주제에 대해 작성된 내용이 너무 적습니다. 그러나 Ajax 프로그래밍의 기본 사항 이상을 배우고 싶다면 준비 상태, 상태 코드 및 요청 자체의 내용을 숙지해야 합니다. 애플리케이션에 문제가 발생하는 경우(항상 그렇습니다), 준비 상태, HEAD 요청 생성 방법 또는 정확히 400 상태 코드의 의미를 올바르게 이해하면 5시간이 아닌 5분 만에 문제를 디버그할 수 있습니다. 다양한 좌절과 혼란 속에서.
먼저 HTTP 준비 상태를 살펴보겠습니다.
HTTP 준비 상태 자세히 살펴보기
이전 기사에서 XMLHttpRequest 개체에 ReadyState라는 속성이 있다는 것을 기억하실 것입니다. 이 속성은 일반적으로 웹 양식이나 페이지의 콘텐츠를 업데이트하기 위해 서버에서 데이터를 읽는 콜백 함수를 사용하여 서버가 요청을 완료했는지 확인합니다. 목록 1은 간단한 예를 보여줍니다(이 시리즈의 이전 기사에 있는 예이기도 합니다. 참고자료 참조).
XMLHttpRequest 또는 XMLHttp: 이름 변경
Microsoft™ 및 Internet Explorer는 Mozilla, Opera, Safari 및 대부분의 타사 브라우저에서 사용되는 XMLHttpRequest 개체 대신 XMLHttp라는 개체를 사용합니다. 단순화를 위해 두 개체를 모두 간단히 XMLHttpRequest라고 부르겠습니다. 이는 웹에서 볼 수 있는 내용과 Internet Explorer 7.0의 요청 개체로 XMLHttpRequest를 사용하려는 Microsoft의 의도와 일치합니다. (이 문제에 대한 자세한 내용은 2부를 참조하세요.)
목록 1. 콜백함수 updatePage()
에서 서버 응답 처리
{
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/n/g, "<br />");
} 또 다른
Alert("상태는 " + request.status);
}
}
이는 분명히 준비 상태의 가장 일반적이고 간단한 사용법입니다. 숫자 "4"에서 알 수 있듯이 몇 가지 다른 준비 상태가 있습니다(이전 기사에서 이 목록도 보았습니다. 참고자료 참조).
· 0: 요청이 초기화되지 않았습니다( open()이 아직 호출되지 않았습니다). .
·1: 요청이 설정되었지만 전송되지 않았습니다(send()가 아직 호출되지 않음).
·2: 요청이 전송되었으며 처리 중입니다(대개 이제 응답에서 콘텐츠 헤더를 얻을 수 있습니다).
·3: 요청이 처리되고 있습니다. 일반적으로 응답에 일부 데이터가 있지만 서버가 아직 응답 생성을 완료하지 않았습니다.
·4: 응답이 완료되었습니다. 서버의 응답을 얻어 사용할 수 있습니다.
Ajax 프로그래밍의 기본보다 더 많은 것을 이해하려면 이러한 상태뿐만 아니라 이러한 상태가 발생하는 시기와 사용 방법도 알아야 합니다. 먼저 각 준비 상태에서 발생할 수 있는 요청 상태를 알아야 합니다. 불행하게도 이는 직관적이지 않으며 몇 가지 특수한 경우가 포함됩니다.
숨겨진 준비 상태
첫 번째 준비 상태는 초기화되지 않은 상태를 나타내는 0(readyState == 0)인 ReadyState 속성을 특징으로 합니다. 요청 객체에 대해 open()이 호출되면 이 속성은 1로 설정됩니다. 일반적으로 한 쌍의 요청을 초기화한 후 즉시 open()을 호출하므로 ReadyState == 0 상태가 거의 표시되지 않습니다. 또한 초기화되지 않은 준비 상태는 실제 애플리케이션에서 실제로 사용되지 않습니다.
그러나 관심을 끌기 위해 ReadyState가 0으로 설정된 경우 이 준비 상태를 얻는 방법을 보여주는 Listing 2를 참조하십시오.
목록 2. 0 준비 상태 가져오기
함수 getSalesData() {
//요청 객체 생성
생성요청();
Alert("준비 상태: " + request.readyState)
// 요청 설정(초기화)
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = 업데이트페이지;
request.send(null);
}
이 간단한 예에서 getSalesData()는 웹 페이지가 요청(예: 버튼 클릭 시)을 시작하기 위해 호출하는 함수입니다. open()을 호출하기 전에 준비 상태를 확인해야 합니다. 그림 1은 이 애플리케이션을 실행한 결과를 보여줍니다.
그림 1. 준비 상태 0
분명히 이것은 당신에게 많은 것을 사지 않습니다; open() 함수가 아직 호출되지 않았는지 확인해야 하는 상황은 거의 없습니다. 대부분의 Ajax 프로그래밍의 실제 세계에서 이 준비 상태의 유일한 용도는 동일한 XMLHttpRequest 객체를 사용하여 여러 기능에 걸쳐 여러 요청을 생성하는 것입니다. 이(흔하지 않은) 경우 새 요청을 생성하기 전에 요청 객체가 초기화되지 않은 상태(readyState == 0)인지 확인해야 할 수 있습니다. 이는 본질적으로 다른 함수가 객체를 동시에 사용하지 않도록 보장합니다.
처리 중인 요청의 준비 상태를 확인합니다
. 0 준비 상태 외에도 요청 개체는 일반적인 요청 및 응답의 여러 다른 준비 상태를 거쳐야 최종적으로 준비 상태 4의 형태로 끝납니다. 이것이 대부분의 콜백 함수에서 if (request.readyState == 4) 줄을 보는 이유입니다. 이는 서버가 요청 처리를 마쳤으며 이제 반환된 요청에 따라 웹 페이지를 업데이트하거나 페이지를 업데이트하는 것이 안전하다는 것을 보장합니다. 서버에서 작업을 수행하는 데이터입니다.
이 상태가 어떻게 발생하는지 보는 것은 매우 간단합니다. 준비 상태가 4인 경우 콜백 함수에서 코드를 실행해야 할 뿐만 아니라 콜백 함수가 호출될 때마다 준비 상태를 인쇄해야 합니다. 목록 3에는 이 기능을 구현하는 예가 나와 있습니다.
0이 4인 경우
여러 JavaScript 함수가 동일한 요청 객체를 사용할 때 요청 객체가 사용 중이 아닌지 확인하기 위해 준비 상태 0을 확인해야 합니다. 이 메커니즘은 문제를 일으킬 수 있습니다. ReadyState == 4는 완료된 요청을 나타내기 때문에 현재 사용되지 않는 준비 상태의 요청 개체가 여전히 4로 설정되어 있는 경우가 많습니다. 이는 서버에서 반환된 데이터가 이미 사용되었지만 사용되지 않았기 때문입니다. 준비 상태로 설정된 이후 변경 사항이 발생했습니다. 요청 객체를 재설정하는 abort() 함수가 있지만 이 함수는 실제로 이 목적으로 사용되지 않습니다. 여러 함수를 사용해야 하는 경우 여러 함수 간에 동일한 개체를 공유하는 것보다 각 함수마다 하나의 함수를 만들어 사용하는 것이 좋습니다.
목록 3. 보기 준비
함수 updatePage() {
// 현재 준비 상태를 출력합니다.
Alert("updatePage()가 준비 상태 " + request.readyState로 호출됨);
}
이 함수를 실행하는 방법을 잘 모르는 경우 함수를 만든 다음 웹 페이지에서 이 함수를 호출하고 서버 측 구성 요소(예: 목록 2에 표시된 함수 또는 이 기사 시리즈의 기능) 1부 및 2부에 제공된 예). 이를 수행하려면 요청을 할 때 콜백 함수를 updatePage()로 설정해야 합니다. 요청 객체의 onreadystatechange 속성을 updatePage()로 설정하세요.
이 코드는 onreadystatechange의 의미를 정확하게 보여줍니다. 요청의 준비 상태가 변경될 때마다 updatePage()가 호출되고 경고가 표시됩니다. 그림 2는 준비 상태가 1인 이 함수를 호출하는 예를 보여줍니다.
그림 2. 준비 상태 1
이 코드를 직접 실행해 볼 수 있습니다. 이를 웹 페이지에 넣고 이벤트 핸들러를 활성화하십시오(버튼을 클릭하거나 필드 사이를 탭하거나 요청을 트리거하기 위해 설정한 방법을 사용하십시오). 이 콜백 함수는 준비 상태가 변경될 때마다 여러 번 실행되며 각 준비 상태에 대한 경고를 볼 수 있습니다. 이는 요청이 진행되는 다양한 단계를 추적하는 가장 좋은 방법입니다.
브라우저 불일치
프로세스에 대한 기본적인 이해를 마친 후 몇 가지 다른 브라우저에서 페이지에 액세스해 보십시오. 브라우저가 이러한 준비 상태를 처리하는 방식이 일관되지 않는다는 점에 유의해야 합니다. 예를 들어, Firefox 1.5에서는 다음과 같은 준비 상태를 볼 수 있습니다:
·1
·2
·3
·4
각 요청 상태가 여기에 표시되므로 이는 놀라운 일이 아닙니다. 그러나 동일한 애플리케이션에 액세스하기 위해 Safari를 사용한다면 뭔가 흥미로운 것을 보게 될 것입니다. Safari 2.0.1의 모습은 다음과 같습니다.
·2
·3
·4
Safari는 실제로 첫 번째 준비 상태를 버리고 그 이유에 대한 명확한 이유는 없지만 이것이 바로 Safari가 작동하는 방식입니다. 이는 또한 중요한 점을 보여줍니다. 서버에서 데이터를 사용하기 전에 요청 상태가 4인지 확인하는 것이 좋지만 각 전환 준비 상태에 의존하도록 작성된 코드는 실제로 브라우저 결과에 따라 다르게 보입니다.
예를 들어 Opera 8.5를 사용하는 경우 표시되는 준비 상태는 더욱 악화됩니다.
·3
·
4마지막으로 Internet Explorer는 다음과 같은 상태를 표시합니다:
·1
·2
·3
·4
귀하의 요청에 문제가 있는 경우 가장 먼저 문제를 확인하는 곳입니다. 가장 좋은 방법은 Internet Explorer와 Firefox에서 이를 테스트하는 것입니다. 4가지 상태를 모두 확인하고 요청의 각 상태를 확인할 수 있습니다.
다음으로 대응측 상황을 살펴보겠습니다.
현미경으로 살펴보는 응답 데이터
요청 프로세스 중에 발생하는 다양한 준비 상태를 이해한 후에는 XMLHttpRequest 객체의 또 다른 측면인 responseText 속성을 살펴볼 차례입니다. 이전 기사에서 소개한 내용을 떠올려 보면 이 속성이 서버에서 데이터를 가져오는 데 사용된다는 것을 알 수 있습니다. 서버가 요청 처리를 마치면 요청 데이터에 응답하는 데 필요한 모든 데이터를 요청의 responseText에 배치할 수 있습니다. 그런 다음 콜백 함수는 목록 1과 목록 4에 표시된 대로 이 데이터를 사용할 수 있습니다.
목록 4. 서버에서 반환된 응답 사용
함수 업데이트페이지() {
if (request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("total-sold");
var netProfitEl = document.getElementById("net-profit");
replacementText(totalSoldEl, newTotal);
/* 새로운 순이익을 계산하세요 */
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
varprofitPerBoard = BoardCost - manCost;
var netProfit =profitPerBoard * newTotal;
/* 판매 양식의 순이익 업데이트 */
netProfit = Math.round(netProfit * 100) / 100;
replacementText(netProfitEl, netProfit);
목록
1은 매우 간단합니다. 목록 4는 조금 더 복잡하지만 둘 다 처음에 준비 상태를 확인하고 responseText 속성의 값을 가져옵니다.
요청의 응답 텍스트 보기
준비 상태와 유사하게 responseText 속성의 값도 요청 수명 동안 변경됩니다. 이 변경 사항을 확인하려면 목록 5에 표시된 코드를 사용하여 요청의 응답 텍스트와 준비 상태를 테스트하세요.
목록 5. responseText 속성
함수 updatePage() {
테스트하기
// 현재 준비 상태를 출력합니다.
Alert("updatePage()가 준비 상태 " + request.readyState +로 호출되었습니다.
" 및 응답 텍스트 '" + request.responseText + "'");
}
이제 브라우저에서 웹 애플리케이션을 열고 요청을 활성화하십시오. 이 코드의 효과를 더 잘 확인하려면 Firefox 또는 Internet Explorer를 사용하세요. 두 브라우저 모두 요청 중에 가능한 모든 준비 상태를 보고할 수 있기 때문입니다. 예를 들어 준비 상태 2에서는 responseText가 정의되지 않습니다(그림 3 참조). JavaScript 콘솔도 열려 있으면 오류가 표시됩니다.
그림 3. 준비 상태 2에 대한 응답 텍스트
그러나 준비 상태 3에서 서버는 적어도 이 예에서는 responseText 속성에 값을 입력했습니다(그림 4 참조).
그림 4. 준비 상태 3에 대한 응답 텍스트
준비 상태가 3인 응답은 각 스크립트, 각 서버, 심지어 각 브라우저마다 다르다는 것을 알 수 있습니다. 그러나 이는 애플리케이션 디버깅에 여전히 매우 유용합니다.
안전한 데이터 획득
모든 문서와 사양에서는 준비 상태가 4일 때만 데이터를 안전하게 사용할 수 있음을 강조합니다. 준비 상태가 3일 때 responseText 속성에서 데이터를 가져올 수 없는 상황은 거의 찾아볼 수 없습니다. 그러나 애플리케이션에서 준비 상태 3에 종속되는 자체 로직을 만드는 것은 좋은 생각이 아닙니다. 일단 준비 상태 3의 완전한 데이터에 의존하는 코드를 작성하면 그 시점의 불완전한 데이터에 대한 책임이 거의 발생합니다.
더 나은 접근 방식은 준비 상태 3에 있을 때 응답이 곧 이루어질 것이라는 피드백을 사용자에게 제공하는 것입니다. Ajax를 사용하고 경고 대화 상자로 사용자를 차단하는 것은 분명히 잘못된 생각이지만, Alert()와 같은 기능을 사용하는 것은 분명히 잘못된 생각입니다. 준비 상태가 변경되면 양식이나 페이지의 필드를 업데이트할 수 있습니다. 예를 들어, 준비 상태 1의 경우 진행률 표시기 너비를 25%로 설정하고, 준비 상태 2의 경우 진행률 표시기의 너비를 50%로 설정하고, 준비 상태 3의 경우 진행률 표시기의 너비를 25로 설정합니다. %. 너비는 75%로 설정되며, 준비 상태가 4일 때 진행률 표시기의 너비는 100%(완료)로 설정됩니다.
물론 이미 본 것처럼 이 방법은 매우 영리하지만 브라우저에 따라 다릅니다. Opera에서는 처음 두 개의 준비 상태를 볼 수 없으며 Safari에서는 첫 번째 준비 상태(1)가 없습니다. 이러한 이유로 이 코드를 연습용으로 남겨두고 이 기사에는 포함하지 않았습니다.
이제 상태 코드를 살펴볼 차례입니다.
HTTP 상태 코드에 대한 심층적인 살펴보기
Ajax 프로그래밍 기술에서 배운 준비 상태와 서버 응답을 사용하면 HTTP 상태 코드를 사용하여 Ajax 애플리케이션에 또 다른 수준의 복잡성을 추가할 수 있습니다. 이 코드에는 Ajax에 대한 새로운 내용이 없습니다. 그들은 웹의 초창기부터 존재해 왔습니다. 웹 브라우저에서 여러 가지 상태 코드를 볼 수 있습니다.
· 401: 인증되지 않음 · 403: 금지됨 · 404: 찾을 수 없음
더 많은 상태 코드를 찾을 수 있습니다(전체 목록은 참고자료 참조). Ajax 애플리케이션에 추가 제어 및 응답 계층(및 더욱 강력한 오류 처리) 메커니즘을 추가하려면 요청 및 응답에서 상태 코드를 적절하게 확인해야 합니다.
200: 모든 것이 정상입니다.
많은 Ajax 애플리케이션에서는 목록 6에 표시된 것처럼 준비 상태를 확인한 다음 서버 응답에서 반환된 데이터를 계속 활용하는 콜백 함수를 볼 수 있습니다.
목록 6. 상태 코드를 무시하는 콜백 함수 function
updatePage() {
if (request.readyState == 4) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/n/g, "<br />");
}
}
이는 Ajax 프로그래밍에 대한 근시안적이고 잘못된 접근 방식임이 밝혀졌습니다. 스크립트에 인증이 필요하고 요청이 유효한 인증서를 제공하지 않는 경우 서버는 403 또는 401과 같은 오류 코드를 반환합니다. 그러나 서버가 요청에 응답했기 때문에 준비 상태는 4로 설정됩니다(응답이 요청에서 예상한 것과 다르지 않더라도). 궁극적으로 사용자는 유효한 데이터를 얻지 못하며 JavaScript가 존재하지 않는 서버 데이터를 사용하려고 시도하면 심각한 오류가 발생할 수 있습니다.
서버가 요청을 완료할 뿐만 아니라 "모두 양호" 상태 코드를 반환하는지 확인하려면 최소한의 노력이 필요합니다. 이 코드는 "200"이며 XMLHttpRequest 객체의 상태 속성을 통해 보고됩니다. 서버가 요청을 완료했을 뿐만 아니라 OK 상태도 보고했는지 확인하려면 목록 7에 표시된 대로 콜백 함수에 또 다른 검사를 추가하세요.
목록 7. 유효한 상태 코드 확인
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/n/g, "<br />");
} 또 다른
Alert("상태는 " + request.status);
}
}
이러한 몇 줄의 코드를 추가하면 문제가 있는지 확인할 수 있으며 사용자는 설명 없이 컨텍스트에서 벗어난 데이터로 구성된 페이지를 보는 대신 유용한 오류 메시지를 보게 됩니다.
리디렉션 및 재라우팅
오류에 대해 자세히 알아보기 전에 Ajax를 사용할 때 걱정할 필요가 없는 문제인 리디렉션에 대해 논의하는 것이 좋습니다. HTTP 상태 코드 중 다음을 포함하는 300 시리즈의 상태 코드입니다.
301: 영구적으로 이동됨 302: 발견(요청이 다른 URL/URI로 리디렉션됨)
·305: 프록시 사용(요청은 요청된 리소스에 액세스하기 위해 프록시를 사용해야 함)
Ajax 프로그래머는 두 가지 이유로 인해 리디렉션 문제에 대해 크게 걱정하지 않을 수 있습니다.
첫째, Ajax 애플리케이션은 일반적으로 특정 서버측을 위해 작성되도록 설계되었습니다. 스크립트, 서블릿 또는 애플리케이션. Ajax 프로그래머는 보지 않고도 사라지는 구성 요소에 대해 덜 명확합니다. 따라서 리소스를 이동했거나 어떤 방법으로 이동했기 때문에 리소스가 이동했다는 사실을 알고 요청에서 URL을 수정하면 이 결과가 다시는 발생하지 않는 경우가 있습니다.
더 중요한 이유는 Ajax 애플리케이션과 요청이 샌드박스에 캡슐화되어 있다는 것입니다. 이는 Ajax 요청을 생성하는 웹 페이지를 제공하는 도메인이 해당 요청에 응답하는 도메인이어야 함을 의미합니다. 따라서 ebay.com에서 제공하는 웹 페이지는 amazon.com에서 실행되는 스크립트에 Ajax 스타일 요청을 할 수 없습니다. ibm.com의 Ajax 애플리케이션은 netbeans.org에서 실행되는 서블릿에 요청할 수 없습니다.
·결과적으로 보안 오류가 발생하지 않고는 귀하의 요청을 다른 서버로 리디렉션할 수 없습니다. 이 경우 상태 코드가 전혀 표시되지 않습니다. 일반적으로 디버그 콘솔에서 JavaScript 오류가 생성됩니다. 따라서 상태 코드에 대해 충분히 생각한 후에는 리디렉션 코드 문제를 완전히 무시할 수 있습니다.
결과적으로 보안 오류가 발생하지 않고는 귀하의 요청을 다른 서버로 리디렉션할 수 없습니다. 이 경우 상태 코드가 전혀 표시되지 않습니다. 일반적으로 디버그 콘솔에서 JavaScript 오류가 생성됩니다. 따라서 상태 코드에 대해 충분히 생각한 후에는 리디렉션 코드 문제를 완전히 무시할 수 있습니다.
오류
상태 코드 200을 받고 300 시리즈 상태 코드를 대부분 무시할 수 있다는 것을 알게 되면 걱정해야 할 유일한 코드 세트는 다양한 유형의 오류를 설명하는 400 시리즈 코드입니다. 목록 7을 다시 보면 오류를 처리할 때 몇 가지 일반적인 오류 메시지만 사용자에게 출력된다는 점을 알 수 있습니다. 이것이 올바른 방향으로 나아가는 단계이기는 하지만, 이러한 메시지는 애플리케이션 작업을 수행하는 사용자와 프로그래머에게 정확히 무엇이 잘못되고 있는지 알려주는 데 여전히 그다지 유용하지 않습니다.
먼저 찾을 수 없는 페이지에 대한 지원을 추가하겠습니다. 이는 대부분의 프로덕션 시스템에서 실제로 발생해서는 안 되지만, 테스트 스크립트의 위치가 변경되거나 프로그래머가 잘못된 URL을 입력하는 경우는 드문 일이 아닙니다. 404 오류를 자연스럽게 보고할 수 있다면 답답한 사용자와 프로그래머에게 더 많은 도움을 줄 수 있습니다. 예를 들어, 서버의 스크립트가 삭제되면 목록 7의 코드를 사용하여 그림 5에 표시된 것과 같은 설명적이지 않은 오류를 사용자에게 표시할 수 있습니다.
극단적인 경우와 어려운 상황
이 시점에서 일부 초보 프로그래머는 이것이 무엇인지 궁금해할 수 있습니다. 알아야 할 사실은 다음과 같습니다. Ajax 요청 중 5% 미만이 2 및 3과 같은 준비 상태와 403과 같은 상태 코드를 사용합니다(실제로 이 비율은 1%에 가까우거나 그보다 더 낮습니다). 이러한 상황은 매우 중요하며 극단적인 경우라고 합니다. 이는 가장 특이한 문제가 발생하는 매우 특정한 상황에서만 발생합니다. 이러한 상황은 흔하지는 않지만 대부분의 사용자가 직면하는 문제의 80%를 차지합니다!
일반 사용자의 경우 애플리케이션이 100번 올바르게 작동한다는 사실은 대개 잊어버리지만, 애플리케이션의 한 가지 실수는 분명하게 기억됩니다. 그들을. 극단적인 경우(또는 어려운 상황)를 잘 처리할 수 있다면 사이트를 다시 방문하는 사용자에게 만족스러운 보상을 제공할 수 있습니다.
그림 5. 일반적인 오류 처리
사용자는 문제가 인증 문제인지, 찾을 수 없는 스크립트(여기의 경우)인지, 사용자 오류인지, 아니면 코드의 다른 부분인지 알 수 없습니다. 간단한 코드를 추가하면 이 오류를 더욱 구체적으로 만들 수 있습니다. 스크립트를 찾을 수 없거나 인증 오류가 발생하는 상황을 처리하는 역할을 담당하는 Listing 8을 참조하세요. 이러한 오류가 발생하면 특정 메시지가 표시됩니다.
목록 8. 유효한 상태 코드 확인
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/n/g, "<br />");
} else if (request.status == 404) {
Alert("요청한 URL을 찾을 수 없습니다.");
} else if (request.status == 403) {
Alert("접근이 거부되었습니다.");
} 또 다른
Alert("상태는 " + request.status);
}
}
이는 여전히 매우 간단하지만 좀 더 유용한 정보를 제공합니다. 그림 6은 그림 5와 동일한 오류를 보여 주지만 이번에는 오류 처리 코드가 정확히 무슨 일이 일어났는지 사용자나 프로그래머에게 더 잘 설명합니다.
그림 6. 특수 오류 처리
자체 애플리케이션에서는 인증 실패 시 사용자 이름과 비밀번호를 지우고 화면에 오류 메시지를 추가하는 것을 고려할 수 있습니다. 유사한 접근 방식을 사용하여 찾을 수 없는 스크립트 또는 기타 400 유형 오류를 더 잘 처리할 수 있습니다. 예를 들어 405는 HEAD 요청 전송과 같은 허용되지 않는 요청 방법이 허용되지 않음을 의미하고 407은 프록시 인증이 필요함을 의미합니다. 그러나 어떤 옵션을 선택하든 서버에서 반환된 상태 코드 처리를 시작해야 합니다.
기타 요청 유형
XMLHttpRequest 객체를 실제로 제어하려면 지시문에 HEAD 요청을 추가하여 이 최종 기능을 구현하는 것을 고려하십시오. 이전 두 기사에서는 GET 요청을 생성하는 방법을 소개했으며 다음 기사에서는 POST 요청을 사용하여 서버에 데이터를 보내는 방법을 배우게 됩니다. 그러나 향상된 오류 처리 및 정보 수집의 정신으로 HEAD 요청을 생성하는 방법을 배워야 합니다.
요청 만들기
HEAD 요청을 만드는 것은 실제로 매우 간단합니다. 목록 9에 표시된 것처럼 첫 번째 매개변수로 "HEAD"("GET" 또는 "POST" 대신)를 사용하여 open() 메서드를 호출합니다.
목록 9. Ajax를 사용하여 HEAD 요청함수 getSalesData() {
생성
생성요청();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = 업데이트페이지;
request.send(null);
}
이와 같은 HEAD 요청을 생성하면 서버는 GET 또는 POST 요청과 같은 실제 응답을 반환하지 않습니다. 대신 서버는 응답의 콘텐츠가 마지막으로 수정된 시기, 요청한 리소스가 존재하는지 여부 및 기타 유용한 정보가 포함된 리소스 헤더만 반환합니다. 이 정보를 사용하여 서버에서 리소스를 처리하고 반환하기 전에 리소스에 대해 알아볼 수 있습니다.
이러한 종류의 요청에 대해 수행할 수 있는 가장 간단한 작업은 모든 응답 헤더의 내용을 출력하는 것입니다. 이는 HEAD 요청을 통해 무엇을 사용할 수 있는지에 대한 아이디어를 제공합니다. 목록 10에서는 HEAD 요청에서 얻은 응답 헤더의 내용을 인쇄하는 간단한 콜백 함수를 제공합니다.
목록 10. HEAD 요청함수 updatePage()
에서 얻은 응답 헤더의 콘텐츠 출력
if (request.readyState == 4) {
경고(request.getAllResponseHeaders());
}
}
서버에 HEAD 요청을 보내는 간단한 Ajax 애플리케이션에서 반환된 응답 헤더를 보여주는 그림 7을 참조하세요.
이러한 헤더를 개별적으로(서버 유형에서 콘텐츠 유형으로) 사용하여 Ajax 애플리케이션에 추가 정보나 기능을 제공할 수 있습니다.
URL 확인하기
URL이 존재하지 않을 때 404 오류를 확인하는 방법을 살펴보았습니다. 이것이 일반적인 문제로 판명되면(특정 스크립트나 서블릿이 누락되었을 수 있음) 전체 GET 또는 POST 요청을 수행하기 전에 URL을 확인하는 것이 좋습니다. 이 기능을 구현하려면 HEAD 요청을 생성한 다음 콜백 함수에서 404 오류를 확인하세요. Listing 11은 간단한 콜백 함수를 보여줍니다.
목록 11. URL이 존재하는지 확인하기
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
Alert("URL이 존재합니다.");
} else if (request.status == 404) {
Alert("URL이 존재하지 않습니다.");
} 또 다른 {
Alert("상태: " + request.status);
}
}
}
솔직히 이 코드의 가치는 그리 크지 않습니다. 서버는 요청에 응답하고 Content-Length 응답 헤더를 채우기 위한 응답을 구성해야 하므로 처리 시간이 절약되지 않습니다. 또한 이는 요청을 생성하고 HEAD 요청을 사용하여 URL이 존재하는지 확인하는 것만큼 시간이 걸립니다. 이는 목록 7에 표시된 대로 오류 코드를 처리하는 대신 GET 또는 POST를 사용하여 요청을 생성하기 때문입니다. 그러나 때로는 현재 사용 가능한 것이 무엇인지 정확히 아는 것이 유용할 수 있습니다. 언제 창의력이 발휘될지, 언제 HEAD 요청이 필요할지 알 수 없습니다.
유용한 HEAD 요청
HEAD 요청이 매우 유용하다고 생각할 수 있는 영역 중 하나는 콘텐츠의 길이나 콘텐츠 유형을 확인하는 것입니다. 이를 통해 요청을 처리하기 위해 많은 양의 데이터를 다시 전송해야 하는지 여부와 서버가 HTML, 텍스트 또는 XML 대신 이진 데이터를 반환하려고 하는지 여부를 결정할 수 있습니다(세 가지 유형의 데이터 모두 JavaScript보다 JavaScript에서 처리하기가 더 쉽습니다). 바이너리 데이터).
이러한 경우 적절한 헤더 이름을 사용하여 XMLHttpRequest 객체의 getResponseHeader() 메서드에 전달하면 됩니다. 따라서 응답 길이를 얻으려면 request.getResponseHeader("Content-Length");를 호출하면 됩니다. 콘텐츠 유형을 얻으려면 request.getResponseHeader("Content-Type");을 사용하세요.
많은 애플리케이션에서 HEAD 요청을 생성하면 기능이 추가되지 않으며 요청 속도가 느려질 수도 있습니다(HEAD 요청을 강제로 응답에 대한 데이터를 가져온 다음 GET 또는 POST 요청을 사용하여 실제로 응답을 얻음). 그러나 스크립트나 서버 측 구성 요소에 대해 확신이 없는 상황에서는 HEAD 요청을 사용하면 실제로 응답 데이터를 처리하거나 응답을 보내는 데 많은 대역폭이 필요하지 않고 일부 기본 데이터를 얻을 수 있습니다.
결론
많은 Ajax 및 웹 프로그래머에게는 이 기사에 제시된 내용이 너무 고급스러워 보일 수 있습니다. HEAD 요청 생성의 가치는 무엇입니까? JavaScript에서 리디렉션 상태 코드를 명시적으로 처리해야 하는 경우는 언제인가요? 이는 좋은 질문입니다. 간단한 응용의 경우 이러한 고급 기술의 가치가 그리 크지 않다는 것이 대답입니다.
그러나 웹은 더 이상 단순한 애플리케이션을 구현해야 하는 곳이 아닙니다. 사용자는 더욱 발전했고 고객은 더 나은 안정성과 더 발전된 오류 보고를 기대하며 애플리케이션이 1%의 시간 동안 다운되면 관리자는 그 때문에 해고당하세요.
따라서 귀하의 작업은 단순한 애플리케이션에만 국한될 수 없으며 XMLHttpRequest에 대한 더 깊은 이해가 필요합니다.
·다양한 준비 상태에 대해 생각하고 이러한 준비 상태가 브라우저마다 어떻게 다른지 이해할 수 있다면 애플리케이션을 빠르게 디버그할 수 있습니다. 준비 상태를 기반으로 몇 가지 창의적인 기능을 개발하고 요청된 상태를 사용자와 고객에게 다시 보고할 수도 있습니다.
·상태 코드를 제어하려는 경우 스크립트 오류, 예상치 못한 응답 및 극단적인 경우를 처리하도록 애플리케이션을 설정할 수 있습니다. 그 결과 모든 것이 괜찮을 때뿐만 아니라 항상 올바르게 작동하는 응용 프로그램이 탄생했습니다.
·HEAD 요청을 생성하고, URL이 존재하는지 확인하고, 파일이 수정되었는지 확인하는 기능을 추가하여 사용자가 유효한 페이지를 얻을 수 있고 사용자가 보는 정보가 최신인지 확인합니다(가장 중요). 이 앱이 얼마나 강력하고 다재다능한지.
이 기사의 목적은 애플리케이션을 멋지게 보이게 만드는 것이 아니라 노란색 스포트라이트를 제거하고 텍스트의 아름다움을 강조하거나 데스크톱처럼 보이도록 돕는 것입니다. 이것들은 모두 Ajax의 기능이지만(다음 몇 개의 기사에서 다룰 것임) 케이크 위의 크림 층과 같습니다. Ajax를 사용하여 애플리케이션이 오류와 문제를 잘 처리할 수 있도록 탄탄한 기반을 구축할 수 있다면 사용자는 사이트와 애플리케이션을 다시 방문하게 될 것입니다. 다음 글에서는 고객을 설레게 만들 직관적인 기술을 추가하겠습니다. (진심으로, 다음 기사를 놓치고 싶지 않으세요!)