This content is likely not relevant anymore. Try searching or browse recent questions.
request after 302 response be pending
The scenario where we have a problem is an SSO authentication scenario. Successful user authentication may trigger redirection. The request after the redirection is always in pending. Direct access to the redirected destination address can be accessed normally.
The captured event information for failed request is as follows：
​t= 94065 [st= 3] -HTTP_TRANSACTION_SEND_REQUESTt= 94065 [st= 3] +HTTP_TRANSACTION_READ_HEADERS [dt=393]
t= 94065 [st= 3] HTTP_STREAM_PARSER_READ_HEADERS [dt=393]
t= 94458 [st= 396] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 302 Found
Server: Web Server
Date: Wed, 01 Apr 2020 06:14:25 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=65
Set-Cookie: ttf=805784545;path=/static;secure
Cache-Control: private
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-ConsoleFrame-Flag: J-CF2.0
Set-Cookie: SID=Set2; Domain=com.cn; Path=/; Secure; HttpOnly
Set-Cookie: agencyID=450d6156e2484b53a371dd1aba59a2a4; Path=/; Secure
Set-Cookie: third-party-access=""; Path=/; Secure
Set-Cookie: J_SESSION_ID=0d48105e35aecef34ed15bd019d5f089cdbd285a07585810; Path=/; Secure; HttpOnly
Location: https://hwconsole.aeonlife.com.cn/console/?region=cn-north-220#/home
Strict-Transport-Security: max-age=31536000; includeSubdomains;
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
t= 94458 [st= 396] -HTTP_TRANSACTION_READ_HEADERS
t= 94458 [st= 396] HTTP_CACHE_WRITE_INFO [dt=0]
t= 94458 [st= 396] NETWORK_DELEGATE_HEADERS_RECEIVED [dt=0]
t= 94459 [st= 397] COOKIE_INCLUSION_STATUS
--> exclusion_reason = "EXCLUDE_INVALID_DOMAIN, DO_NOT_WARN"
--> operation = "store"
t= 94459 [st= 397] +URL_REQUEST_DELEGATE_RECEIVED_REDIRECT [dt=220776+]
t=315235 [st=221173] Latest Update Latest Updates (0)
Recommended Answer Recommended Answers (0)
Relevant Answer Relevant Answers (0)
Our automated system analyzes the replies to choose the one that's most likely to answer the question.
All Replies (18)
Recommended Answer
Relevant Answer
it happend in
chrome version ：80.0.3987.149（stable） （32 bit） recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
I have the same problem/scenario. We are also developing a SSO but in our case, the redirect remains pending only some times. The last chrome event is
t=89297 [st= 29] +URL_REQUEST_DELEGATE_RECEIVED_REDIRECT [dt=6595+]
t=95892 [st=6624]
It is really frustrating. Maybe someone can give us some hints.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
Same here - SSO scenario. Pending request issue happens on almost every login in fresh incognito window. After pressing login again, and thus performing another POST request, it always works ok.
​t=11338 [st= 0] +HTTP_TRANSACTION_READ_HEADERS [dt=110]t=11338 [st= 0] HTTP_STREAM_PARSER_READ_HEADERS [dt=110]t=11448 [st= 110] HTTP_TRANSACTION_READ_RESPONSE_HEADERS --> HTTP/1.1 302 Server: nginx Date: Thu, 16 Apr 2020 16:30:34 GMT Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: http://localhost:8080 Vary: Origin Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials Set-Cookie: [...] X-Frame-Options: DENY Set-Cookie: [...] Location: http://localhost:5000/authorize?code=[...]t=11448 [st= 110] -HTTP_TRANSACTION_READ_HEADERSt=11448 [st= 110] HTTP_CACHE_WRITE_INFO [dt=0]t=11448 [st= 110] HTTP_CACHE_WRITE_DATA [dt=0]t=11448 [st= 110] HTTP_CACHE_WRITE_INFO [dt=0]t=11448 [st= 110] NETWORK_DELEGATE_HEADERS_RECEIVED [dt=0]t=11448 [st= 110] COOKIE_INCLUSION_STATUS --> domain = "localhost" --> name = "[...]" --> operation = "store" --> path = "/" --> status = "INCLUDE, DO_NOT_WARN"t=11448 [st= 110] COOKIE_INCLUSION_STATUS --> domain = "localhost" --> name = "[...]" --> operation = "store" --> path = "/" --> status = "INCLUDE, DO_NOT_WARN"t=11448 [st= 110] URL_REQUEST_DELEGATE_RECEIVED_REDIRECT [dt=5211]t=16659 [st=5321] CANCELLED
Google Chrome: 81.0.4044.92 (Official) (64-bit)
Version: e98e6f21168a55e7ba57202f56323911cd9d31d1-refs/branch-heads/4044@{#883}
OS: Linux
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
I have the same problem with 81.0.4044.138 (macoOSCatalina) (a 64 bit). Any solutions?
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
Exact same issue, really hard to reproduce once you get a successful request happening, seems to surface more on a vpn connection. I can see connection closed events but then it is as if Chrome forgets about the pending request and will never send it, I have had the tab open for more than a day and will never recover.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
We have also recently started to experience the same issue with an old classic ASP (!) login page that has been around and has worked for ages. Redirect after successfully login sometimes stops in "pending" in Chrome, but not always. Hard to reproduce. We have not noted problem this in any other browsers.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
Seeing the same kind of problem - difficult to reproduce consistently in some environments, but happening every time for one customer using Chromebooks running ChromeOS version 79, 80, and 81.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
Affected by the same issue in current stable version of Chrome (81.0.4044.138, Windows 10 x64 and Linux x64).
Disabling all extensions and using the Incognito mode doesn't help. Purging cache won't help, either. However, Guest mode is not affected by this problem.
A sample netlog taken from Guest mode looks like this:​
t=20545 [st=327] -HTTP_TRANSACTION_READ_HEADERSt=20545 [st=327] HTTP_CACHE_WRITE_INFO [dt=1]t=20546 [st=328] NETWORK_DELEGATE_HEADERS_RECEIVED [dt=0]t=20546 [st=328] COOKIE_INCLUSION_STATUS --> operation = "store" --> status = "INCLUDE, DO_NOT_WARN"t=20546 [st=328] URL_REQUEST_DELEGATE_RECEIVED_REDIRECT [dt=4]t=20550 [st=332] URL_REQUEST_REDIRECTED --> location = "[...]"t=20550 [st=332] -URL_REQUEST_START_JOBHowever, in Incognito the request is stuck at
URL_REQUEST_DELEGATE_RECEIVED_REDIRECT, for example:t=36188 [st= 464] -HTTP_TRANSACTION_READ_HEADERSt=36188 [st= 464] HTTP_CACHE_WRITE_INFO [dt=0]t=36188 [st= 464] NETWORK_DELEGATE_HEADERS_RECEIVED [dt=0]t=36188 [st= 464] COOKIE_INCLUSION_STATUS --> operation = "store" --> status = "INCLUDE, DO_NOT_WARN"t=36189 [st= 465] URL_REQUEST_DELEGATE_RECEIVED_REDIRECT [dt=9072]t=45261 [st=9537] CANCELLEDt=45261 [st=9537] -REQUEST_ALIVEAs can be inferred from the netlog and packet capture results, the server did send the response back to client. However Chrome seems to be stuck here, and status in Devtools doesn't update to reflect the reality: After the request is canceled, Devtools' timing panel says it "Stalled" for this time period, and no request has been sent.
I guess this bug should be put forward to https://bugs.chromium.org/p/chromium/issues/entry so that Chromium's developers can look into this issue, however nobody seems to have done this.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
I have the same problem with 81.0.4044.138 (64 bit) ，and It only happens in a few devices
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
Recommended Answer
Relevant Answer
Yes, it seems like that in Chrome Version 85.0.4183.83 the issue has been fixed and I can not reproduce the issue anymore.
recommended this
marked this as an answer
Recommended based on info available
Our automated system analyzes replies to choose the one that's most likely to answer the question. If it seems to be helpful, we may eventually mark it as a Recommended Answer.
This question is locked and replying has been disabled.
Link to post
Delete post?
This will remove the reply from the Answers section.
Notifications are off
Your notifications are currently off and you won't receive subscription updates. To turn them on, go to Notifications preferences on your Profile page.
This reply is no longer available.
Badges
Some community members might have badges that indicate their identity or level of participation in a community.
