jQuery Ajax 요청이 전송되지 않고 취소됨

Microsoft의 World-Wide Telescope 앱에 스크립트를 연결하려고합니다. 후자는 포트 5050에서 명령을 수신합니다. 브라우저와 동일한 시스템에서 실행 중입니다 (현재 Chrome이지만 Firefox 7 및 IE 9의 동작은 동일 함).

내 문제로 XSS 제한을 제거하기 위해 원본 html 파일과 함께 "Access-Control-Allow-Origin : *"헤더를 보내고 있습니다.

WWT에 액세스하는 코드는 다음과 같습니다.

$.ajax({
    type: 'POST',
    url: url,
    data: data,
    crossDomain: true,
    success: success,
    dataType: dataType
});

이 경우 url은 "http : //127.0.0.1 : 5050 / layerApi.aspx? cmd = new & ..."입니다 (분명히 ...은 여기에서 몇 가지 추가 매개 변수의 축약 형입니다).

Chrome의 네트워크 진단을 보면 다음과 같은 것을 볼 수 있습니다.

Request URL:http://127.0.0.1:5050/layerApi.aspx?cmd=new&...
Request Headersview source
Accept:application/xml, text/xml, */*; q=0.01
Content-Type:application/x-www-form-urlencoded
Origin:http://gwheeler4
Referer:http://gwheeler4/conceptconnect.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

요청이 나가고 있습니다. WWT가 새 레이어를 만드는 것을 봅니다. 그러나 콜백을받지 못합니다. 호출되는 오류 콜백을 추가했지만 jqXHR 객체의 오류 속성은 "오류"이고 상태는 0입니다. Chrome에서 네트워크 요청을 보면 "(취소됨)"이 상태로 표시되고 응답이 없습니다. .

동일한 URL을 새 브라우저 탭에 붙여 넣으면 응답이 예상 XML임을 알 수 있습니다.

물론 여기서 차이점은 이것이 POST가 아니라 GET이라는 것입니다. 그러나 스크립트에서 시도했지만 차이가 없습니다.

나는 이것에 꽤 당황스럽고 신선한 아이디어를 고맙게 생각합니다.

다른 사람이이 문제를 겪는다면 우리가 가진 문제는 우리가 링크에서 ajax 요청을하고 링크를 따라가는 것을 막지 않는다는 것입니다. 따라서 onclick속성 에서이 작업을 수행하는 경우 return false;에도 확인하십시오 .

Chrome을 사용하는 경우 표준 Chrome 네트워킹 패널에서 (canceled)요청 의 근본 원인을 확인하기에 충분한 정보를 볼 수 없습니다 .

chrome://net-internals/#events전송중인 쿠키에 대한 숨겨진 리디렉션 / 보안 정보 등 전송중인 요청의 세부 정보를 표시하는 것을 사용해야합니다 .

예를 들어 다음은 내 쿠키가 하위 도메인간에 전송되지 않아 네트워크 추적에서 볼 수 없었던 리디렉션을 보여줍니다.

t=1374052796448 [st=  1]   +URL_REQUEST_START_JOB  [dt=261]
                            --> load_flags = 143540481 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VALIDATE_CACHE | VERIFY_EV_CERT)
                            --> method = "GET"
                            --> priority = 2
                            --> url = "https://...."
...
t=1374052796708 [st=261]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                --> HTTP/1.1 302 Moved Temporarily
                                    Content-Type: text/html
                                    Date: Wed, 17 Jul 2013 09:19:56 GMT
...
t=1374052796709 [st=262]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=0]
t=1374052796709 [st=262]        CANCELLED
t=1374052796709 [st=262]   -URL_REQUEST_START_JOB
                            --> net_error = -3 (ERR_ABORTED)

제 경우 type='submit'에는 양식을 제출할 때 ajax 히트가 가기 전에 페이지가 다시로드되었으므로 간단한 해결책이 필요했습니다 type="button". 유형을 지정하지 않으면 submit기본적으로 지정해야합니다.type="button"

type='submit' => type='button'

또는

유형 없음 => type='button'

비슷한 문제가있었습니다. 제 경우에는 아파치 서버 + django에서 웹 서비스를 사용하려고합니다 (서비스는 직접 작성했습니다). 나는 당신과 같은 출력을 가지고 있었다. Chrome은 FF가 괜찮은 동안 취소되었다고 말합니다. ajax 대신 브라우저에서 직접 서비스에 액세스하려고 시도하면 작동합니다. 인터넷 검색을 통해 일부 최신 버전의 아파치가 응답 헤더에서 응답 길이를 올바르게 설정하지 않는다는 것을 알았으므로 수동으로 수행했습니다. 장고로 내가해야 할 일은 :

response['Content-Length'] = len(content)

액세스하려는 서비스를 제어 할 수있는 경우 사용중인 플랫폼에서 응답 헤더를 수정하는 방법을 알아보십시오. 그렇지 않으면 서비스 제공 업체에 문의하여이 문제를 해결해야합니다. 분명히 FF 및 다른 많은 브라우저는이 상황을 올바르게 처리 할 수 ​​있지만 Chrome 디자이너는 지정된대로 처리하기로 결정했습니다.

비슷한 문제가있었습니다. chrome : // net-internals / # events를 사용하여 내 문제가 자동 리디렉션으로 인한 것임을 알 수있었습니다. 내 get 요청이 onload 스크립트에서 시작되었습니다. URL은 " http://example.com/inner-path " 형식 이었고 301은 "/ inner-path"로 영구적으로 리디렉션되었습니다. 문제를 해결하기 위해 URL을 "/ inner-path"로 변경했으며 문제가 해결되었습니다. 나는 아직도 일주일 전에 작동했던 스크립트가 갑자기 나에게 문제를 일으키는 이유를 모르겠습니다. 누군가에게 도움이되기를 바랍니다.

(Web Forms ASP.NET 사용)

내 문제는 서버 측 클릭 이벤트 설정이있는 제출 버튼의 클릭 이벤트에서 Ajax를 시작하려고했습니다. 내가 버튼을 단순한 버튼을했습니다 (예 <input type="button">)

나는 똑같은 문제가 있었는데, 임시 방식으로 iframe을 만들었고 ajax가 완료되기 전에 iframe을 제거했기 때문에 브라우저가 내 ajax 요청을 취소했습니다.

@Kazetsukai의 답변을 확장하면 사용자가 링크를 클릭하여 AJAX 요청을하는 경우이 문제가 발생할 수 있습니다.

다음과 같이 링크를 설정 한 경우 :

<a href="#" onclick="soAjax()">click me!</a>

그리고 다음과 같은 자바 스크립트 핸들러 :

soAjax() {
    $.ajax({ ... all your lovely parameters ... });       
}

브라우저가 링크를 따라 가고 진행중인 요청을 취소하는 것을 방지하려면 클릭 이벤트 전파를 추가 return false하거나 e.preventDefault()중지 해야합니다 .

soAjax() {
   $.ajax({ ... etc ... });
   return false;
}

또는:

soAjax(e) {
   $.ajax({ ... etc ... });
   e.preventDefault();
}

AJAX 요청이 삭제 될 때 두 가지 가능성이 있습니다 (Cross-Origin 요청이 아닌 경우).

1. 이벤트에 대한 요소의 기본 동작을 방해하지 않습니다.
2. AJAX의 시간 초과를 너무 낮게 설정했거나 네트워크 / 애플리케이션 백엔드 서버가 느립니다.

1)에 대한 해결책 : 이벤트 핸들러에 return false;또는 추가하십시오 e.preventDefault();.

2)에 대한 해결책 : AJAX 요청을 구성하는 동안 시간 초과 옵션을 추가합니다. 아래 예.

$.ajax({
    type: 'POST',
    url: url,
    timeout: 86400,
    data: data,
    success: success,
    dataType: dataType
});

교차 출처 요청의 경우 CORS (Cross-Origin Resource Sharing) HTTP 헤더를 확인하십시오.

http를 사용하여 https가 필요한 URL을 요청할 때이 오류가 발생했습니다. ajax 호출이 리디렉션을 처리하지 않는 것 같습니다. 이것은 crossDomain ajax 옵션이 true로 설정된 경우에도 마찬가지입니다 (JQuery 1.5.2에서).

제 경우에는 Apache의 mod-rewrite가 URL과 일치하고 요청을 https로 리디렉션했습니다.

chrome : // net-internals / # events에서 요청을 확인하세요.

요청의 내부 로그가 표시됩니다. 리디렉션을 확인하십시오.

나는 같은 문제가 있었지만 제 경우에는 쿠키 문제로 판명되었습니다. 백엔드에서 작업하는 사람들은 우리가 앱에 로그인 할 때 설정 한 JSESSIONID 쿠키의 경로를 변경했으며, 내 컴퓨터에는 해당 이름의 이전 쿠키가 있지만 이전 경로가 있습니다. 그래서 브라우저 (Chrome)에 로그인을 시도했을 때 JSESSIONID라는 두 개의 쿠키를 다른 값으로 서버에 보냈습니다.이 쿠키는 당연히 혼란스러워서 요청을 취소했습니다. 내 컴퓨터에서 쿠키를 삭제하면 문제가 해결되었습니다.

이 오류는 더 으스스한 방식으로 발생했습니다. js가 완료된 후 네트워크 탭과 chrome : // net-internals / # events에 요청이 표시되지 않았습니다. 오류 callcack에서 js를 일시 중지하면 네트워크 탭에 요청이 (취소됨)으로 표시되었습니다. 는 웹 페이지에서 몇 가지 유사한 요청 중 정확히 하나 (항상 동일)에 대해 일관되게 호출되었습니다. Chrome을 다시 시작한 후 오류가 다시 발생하지 않았습니다!

Firefox 에서 취소했습니다 . 일부 ajax-call은 나에게는 완벽하게 작동하지만 실제로 사용해야했던 동료에게는 실패했습니다.

위에서 언급 한 Chrome 트릭을 통해 이것을 확인했을 때 의심스러운 것이 없습니다. 방화범에서 확인할 때 두 번의 맬 리큘 러스 호출 후 '로드 중'애니메이션이 표시되고 결과 탭이 없습니다.

해결책 은 매우 간단했습니다. 기록으로 이동하여 웹 사이트를 찾고, 오른쪽 클릭-> 웹 사이트 삭제.
삭제하지 말고 잊어 버리십시오.

그 후에는 더 이상 문제가 없습니다. 내 생각 엔 .htaccess와 관련이 있습니다.

제 경우에는 URL의 후행 슬래시가 누락되었습니다. 후행 슬래시를 추가하면 문제가 해결되었습니다.

Dropzone.js 케이스의 경우. 제 경우에는 기본적으로 timeout옵션 값이 너무 낮기 때문에 발생했습니다 . 따라서 필요에 따라 늘리십시오.

{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}

특정 3G 네트워크에서이 문제가 발생했습니다. chrome : // net-internals / # events
에서 DELETE 요청에 항상 실패 net_error = -101합니다.

다른 네트워크는 정상적으로 작동하므로 프록시 서버에 결함이 있다고 가정합니다.