I'am using a RESTful API with CORS. Sometimes (can't reproduce when/why it happend) a AJAX-Request is aborted by the client and no response comes up. This happends not only in chrome, also other browser are effected. I tried debugging a lot and searched a lot for a solution, but I didn't find one right now. All the requests were procceed by the server were well, only the reponse is blocked by client.
The following is a chrome://net-internals/#events based on the request which is aborted by errornet_error = -3 (ERR_ABORTED). Mostly this problem comes up while using SSL, but SSL is not in use.
2681: URL_REQUEST
http://solid-rm-api/api/role/create
Start Time: 2016-02-23 15:55:16.152
t=97023 [st= 0] +REQUEST_ALIVE [dt=1930]
t=97023 [st= 0] URL_REQUEST_DELEGATE [dt=0]
t=97023 [st= 0] +URL_REQUEST_START_JOB [dt=1930]
--> load_flags = 34626 (BYPASS_CACHE | DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
--> method = "POST"
--> priority = "LOW"
--> upload_id = "0"
--> url = "http://solid-rm-api/api/role/create"
t=97023 [st= 0] URL_REQUEST_DELEGATE [dt=0]
t=97023 [st= 0] HTTP_CACHE_GET_BACKEND [dt=0]
t=97023 [st= 0] URL_REQUEST_DELEGATE [dt=0]
t=97023 [st= 0] +HTTP_STREAM_REQUEST [dt=1]
t=97023 [st= 0] HTTP_STREAM_REQUEST_STARTED_JOB
--> source_dependency = 2683 (HTTP_STREAM_JOB)
t=97024 [st= 1] HTTP_STREAM_REQUEST_BOUND_TO_JOB
--> source_dependency = 2683 (HTTP_STREAM_JOB)
t=97024 [st= 1] -HTTP_STREAM_REQUEST
t=97024 [st= 1] +HTTP_TRANSACTION_SEND_REQUEST [dt=0]
t=97024 [st= 1] HTTP_TRANSACTION_SEND_REQUEST_HEADERS
--> POST /api/role/create HTTP/1.1
Host: solid-rm-api
Connection: keep-alive
Content-Length: 404
Pragma: no-cache
Cache-Control: no-cache
Origin: http://127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
App-Token: ABC
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Accept: application/json, text/plain, */*
Token: 123123123123123123123123
Referer: http://127.0.0.1:8080/src/
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
t=97024 [st= 1] HTTP_TRANSACTION_SEND_REQUEST_BODY
--> did_merge = true
--> is_chunked = false
--> length = 404
t=97024 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
t=97024 [st= 1] +HTTP_TRANSACTION_READ_HEADERS [dt=1929]
t=97024 [st= 1] +HTTP_STREAM_PARSER_READ_HEADERS [dt=1929]
t=98953 [st=1930] CANCELLED
t=98953 [st=1930] -URL_REQUEST_START_JOB
--> net_error = -3 (ERR_ABORTED)
t=98953 [st=1930] URL_REQUEST_DELEGATE [dt=0]
t=98953 [st=1930] -REQUEST_ALIVE
Please let me know if you need more information.
Coming back to this after months. It has turned out that net_error = -3 (ERR_ABORTED) is allways an timeout abort state fired by the application itself. In our case the XHR-Timeout was globally overriden by an third party library. It was set to 2000ms by this library. In that way some of our request which took longer than 2000ms were aborted by the client. The result is net_error = -3 (ERR_ABORTED).
If you are facing the same problem. Check your codes and ensure that the timeout set in your application is configured for your needs.