4 ms·

I can replicate this behavior fairly easily in a browser. 1. Open incognito window in Chrome 2. Visit https://t.co/4fs609qwWt -> 5s delay 3. Open a secon

by ender7 3y ago

I can replicate this behavior fairly easily in a browser. 1. Open incognito window in Chrome 2. Visit https://t.co/4fs609qwWt -> 5s delay 3. Open a second tab in the same window -> no delay 4. Close window, start a new incognito session 5. Visit https://t.co/4fs609qwWt -> 5s delay returns

xslowzone 3y ago
The reason there isn't a delay the second click is because the redirect is cached locally in your browser. Your humble anonymous tipster would appreciate if you do a little legwork.
- hk__2 3y ago
  > The reason there isn't a delay the second click is because the redirect is cached locally in your browser. No, because it’s not an HTTP redirect. It’s an HTML page that redirects you using a meta tag, something that the browser doesn’t cache.
  - xslowzone 3y ago
    Your humble anonymous tipster notes to their skeptical audience that browsers are capable of caching all sorts of things, even something as peculiar as an HTML page.
    - hk__2 3y ago
      > browsers are capable of caching all sorts of things, even something as peculiar as an HTML page. Yes, and this is irrelevant to your previous comment: caching the HTML doesn’t cache the redirect itself.
      - xslowzone 3y ago
        You can lead a horse to water, but you can't make him drink. The delay was not on the HTML page.
        hk__2 3y ago
        > The delay was not on the HTML page. Nobody is saying that.
PenguinCoder 3y ago
What is that attempting to prove or replicate? Here's a simpler test I think replicates what I am indicating in GP comment, with regards to cookie handling: Not passing a cookie to the next stage; pure GET request: $ time curl -s -A "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" -e ";auto" -L https://t.co/4fs609qwWt > nocookie.html real 0m4.916s user 0m0.016s sys 0m0.018s Using `-b` to pass the cookies _(same command as above, just adding `-b`)_ $ time curl -s -b -A "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" -e ";auto" -L https://t.co/4fs609qwWt > withcookie.html real 0m1.995s user 0m0.083s sys 0m0.026s Look at the differences in the resulting files for 'with' and 'no' cookie. One redirect works in a timely manner. The other takes the ~4-5 seconds to redirect.
- mzs 3y ago
  In your second example you are passing the cookie file named ./-A then trying to GET the URL "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" followed by https://t.co/4fs609qwWt https://t.co/4fs609qwWt
- lapcat 3y ago
  You're completely missing the point, which is that the 5 second delay doesn't exist at all for most t.co links, even without cookies. The delay only exists for a few Musk-hated domains.

by ender7 3y ago

xslowzone 3y ago

The reason there isn't a delay the second click is because the redirect is cached locally in your browser. Your humble anonymous tipster would appreciate if you do a little legwork.

hk__2 3y ago
> The reason there isn't a delay the second click is because the redirect is cached locally in your browser. No, because it’s not an HTTP redirect. It’s an HTML page that redirects you using a meta tag, something that the browser doesn’t cache.
- xslowzone 3y ago
  Your humble anonymous tipster notes to their skeptical audience that browsers are capable of caching all sorts of things, even something as peculiar as an HTML page.
  - hk__2 3y ago
    > browsers are capable of caching all sorts of things, even something as peculiar as an HTML page. Yes, and this is irrelevant to your previous comment: caching the HTML doesn’t cache the redirect itself.
    - xslowzone 3y ago
      You can lead a horse to water, but you can't make him drink. The delay was not on the HTML page.
      - hk__2 3y ago
        > The delay was not on the HTML page. Nobody is saying that.

PenguinCoder 3y ago

What is that attempting to prove or replicate? Here's a simpler test I think replicates what I am indicating in GP comment, with regards to cookie handling: Not passing a cookie to the next stage; pure GET request: $ time curl -s -A "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" -e ";auto" -L https://t.co/4fs609qwWt > nocookie.html real 0m4.916s user 0m0.016s sys 0m0.018s Using `-b` to pass the cookies _(same command as above, just adding `-b`)_ $ time curl -s -b -A "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" -e ";auto" -L https://t.co/4fs609qwWt > withcookie.html real 0m1.995s user 0m0.083s sys 0m0.026s Look at the differences in the resulting files for 'with' and 'no' cookie. One redirect works in a timely manner. The other takes the ~4-5 seconds to redirect.

mzs 3y ago
In your second example you are passing the cookie file named ./-A then trying to GET the URL "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0" followed by https://t.co/4fs609qwWt https://t.co/4fs609qwWt
lapcat 3y ago
You're completely missing the point, which is that the 5 second delay doesn't exist at all for most t.co links, even without cookies. The delay only exists for a few Musk-hated domains.