Retry XMLHttpRequest Carefully • Hacker News Board

Re: Retry XMLHttpRequest Carefully

#21

Post by pxx » Wed, Jun 29, 2022, 1:29 AM UTC

indemnity wrote: post #12

joshstrange wrote: post #4

This post reminded of a /fun/ bug I ran into at my last job. The root of the issue was our server was returning a 408 timeout error when something timed out on the backend. Astute readers might immediately notice an issue with that code, mainly that it's for a /client/ timeout not 504 (server timeout). Since we controlled the client and server you might think it doesn't matter much, as long as the client knows how to…

Really curious what the use case is for dev tools hiding a network request from you? Sure, don't display it in the UI, but if the browser is retrying something I sure want to know about it when debugging! Odd.

It's likely being retried on a lower level, similar to the sibling comment about CORS.

Dev tools are not intentionally hiding the retry from you; from its perspective it's asking the networking layer to fetch a page, and the fact that that layer retries beneath the scenes is invisible to it.

Re: Retry XMLHttpRequest Carefully

#22

Post by easrng » Wed, Jun 29, 2022, 7:46 AM UTC

nemothekid wrote: post #20

e12e wrote: post #5

Very nice write-up. I'd be curious to see it using fetch rather than the older xhr Api - that would make more sense as a library today I think? Or are there compelling reasons to stick with xhr in a post-ie world?

The only thing I’ve seen that I’ve hit recently is fetch doesn’t have a progress API. Use case: I was fetching a large image from a server to render into a canvas and I wanted to show a progress bar for the download. AFAIK there is no way to do this with fetch

You need to consume the body stream manually: https://fetch-progress-demo.glitch.me/

Re: Retry XMLHttpRequest Carefully

#23

Post by Nextgrid » Wed, Jun 29, 2022, 11:05 AM UTC

joshstrange wrote: post #4

This post reminded of a /fun/ bug I ran into at my last job. The root of the issue was our server was returning a 408 timeout error when something timed out on the backend. Astute readers might immediately notice an issue with that code, mainly that it's for a /client/ timeout not 504 (server timeout). Since we controlled the client and server you might think it doesn't matter much, as long as the client knows how to…

I had a similar problem with unusual status codes in Safari which caused lots of confusion. If you give it a 204 (example: http://httpbin.org/status/204), weird things happen - it doesn't even change the currently displayed page to a blank one, the URL bar behavior is undefined (the URL bar doesn't change unless the developer tools are open) and the request doesn't appear in the developer tools either.