network tab Status = (canceled)

瀏覽次數:23,688 次
跳到第一則未讀訊息

tony.d...@gmail.com

未讀,
2015年10月23日 上午11:28:262015/10/23
收件者:net-dev
Hi,
On one particular page where we are sending a cross domain HTTP OPTIONS and POST, one of them is always reported as canceled in Developer Tools/Network tab. This AJAX request corresponds to a user's click on a page. Other HTTP OPTIONS and POST events work fine. The flow of HTTP requests are something like the following:

Chrome performs pre-flight automatically.
HTTP OPTIONS
Request Headers:
Access-Control-Request-Headers: content-type, x-si-eventbody
Access-Control-Request-Method: POST
...
Response Headers:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-SI-EventBody (customer header)
Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: (origin of caller)
...
Status Code: should be 200 OK


HTTP POST
Request Headers:
Content-Type: application/x-www-form-urlencoded,charset=UTF-8
Body: form-urlencoded name/value pairs
ResponseHeaders:
Status Code: should be 200 OK.

When the OPTIONS request is canceled, chrome does not try to send the POST. Other times the OPTIONS passes with 200 OK and the POST request is canceled.

The network tab reports such cancellations as follows:

Name Method Status Type Initiator Size Time
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OPTIONS or POST (canceled) xhr 0 - OPTIONS, ~2k - POST always < 500ms


Programmatically, the AJAX call did NOT timeout. It is not obvious to why chrome is cancelling this request. I also enabled net-internals but did not see anything noteworthy. What is the best way to dig deeper to find why chrome is canceling certain requests.

Thanks

Matt Menke

未讀,
2015年10月23日 上午11:33:402015/10/23
收件者:tony.d...@gmail.com、Joel Weinberger、Mike West、net-dev
[+mkwst, +jww]  Who I consider, rightly or wrongly, to be people who know something about CORS requests.

Cancellations are generally issue from the renderer process.  Not sure how much knowledge there is about that side of things on net-dev.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/dbcde524-5c09-4346-8d04-d04b2818759d%40chromium.org.

Vijay Mesa

未讀,
2017年3月23日 清晨5:49:542017/3/23
收件者:net-dev、tony.d...@gmail.com

Hi Tony,

Not sure if you found a solution yet, but I recently got into the same problem and just found an answer. This could be possibly due to Cross-Origin requests.
Refer to the below links: Hope it helps :)
http://twincreations.co.uk/ajax-request-canceled-status-with-no-http-header/
https://en.wikipedia.org/wiki/Same-origin_policy

Best,
Vijay

mveer....@gmail.com

未讀,
2017年4月4日 清晨6:26:482017/4/4
收件者:net-dev、tony.d...@gmail.com、jitend...@nagarro.com
Hi,

I am facing chrome request cancel in case of CDN request. After doing manual purge from azure portal there is no error come. I am not sure how chrome behavior related to CDN purge?

If we consider it as CORS issue then when we purge from CDN how it started working?

mveer....@gmail.com

未讀,
2017年4月11日 清晨6:10:212017/4/11
收件者:net-dev、tony.d...@gmail.com
Hi Guys,

Any response????

Regards
Mahaveer

Xun Fu

未讀,
2018年11月1日 清晨5:29:232018/11/1
收件者:net-dev、tony.d...@gmail.com
回覆所有人
回覆作者
轉寄
0 則新訊息