# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 4
# self = https://watcher.sour.is/conv/vyiax6a
Can someone explain this?
Open this page in Firefox or Chromium:
https://movq.de/v/f9c0330a69/script.html
Feel free to inspect it using curl first. There are 500 <script> tags in the header, all of them point to non-existent files, so you’ll just get 404 for everything.
What I’m seeing is this:
https://movq.de/v/a8818b7210/requests.jpg
1. The browser fetches script.html itself.
2. The browser goes on to retrieve all 500 dead script sources. It does that in parallel using several workers.
3. Once it’s done with that, it *starts over* and retrieves all 500 scripts *again*, but only using one worker this time.
Why is the browser doing that? 🤔
This only happens in Firefox and Chromium, not in my WebKit browser (WebKit only does 500 requests). It also doesn’t happen with <link> tags in the header, nor <img> tags in the body:
- https://movq.de/v/f9c0330a69/link.html
- https://movq.de/v/f9c0330a69/img.html
I’ve seen this on nginx, OpenBSD httpd, and some node.js “web server” now, so I don’t think it’s related to the server.
🤔 😕
Can someone explain this?
Open this page in Firefox or Chromium:
https://movq.de/v/f9c0330a69/script.html
Feel free to inspect it using curl first. There are 500 <script> tags in the header, all of them point to non-existent files, so you’ll just get 404 for everything.
What I’m seeing is this:
https://movq.de/v/a8818b7210/requests.jpg
1. The browser fetches script.html itself.
2. The browser goes on to retrieve all 500 dead script sources. It does that in parallel using several workers.
3. Once it’s done with that, it *starts over* and retrieves all 500 scripts *again*, but only using one worker this time.
Why is the browser doing that? 🤔
This only happens in Firefox and Chromium, not in my WebKit browser (WebKit only does 500 requests). It also doesn’t happen with <link> tags in the header, nor <img> tags in the body:
- https://movq.de/v/f9c0330a69/link.html
- https://movq.de/v/f9c0330a69/img.html
I’ve seen this on nginx, OpenBSD httpd, and some node.js “web server” now, so I don’t think it’s related to the server.
🤔 😕
Can someone explain this?
Open this page in Firefox or Chromium:
https://movq.de/v/f9c0330a69/script.html
Feel free to inspect it using curl first. There are 500 <script> tags in the header, all of them point to non-existent files, so you’ll just get 404 for everything.
What I’m seeing is this:
https://movq.de/v/a8818b7210/requests.jpg
1. The browser fetches script.html itself.
2. The browser goes on to retrieve all 500 dead script sources. It does that in parallel using several workers.
3. Once it’s done with that, it *starts over* and retrieves all 500 scripts *again*, but only using one worker this time.
Why is the browser doing that? 🤔
This only happens in Firefox and Chromium, not in my WebKit browser (WebKit only does 500 requests). It also doesn’t happen with <link> tags in the header, nor <img> tags in the body:
- https://movq.de/v/f9c0330a69/link.html
- https://movq.de/v/f9c0330a69/img.html
I’ve seen this on nginx, OpenBSD httpd, and some node.js “web server” now, so I don’t think it’s related to the server.
🤔 😕
@movq WTF, this is really weird! I can confirm this with my Firefox, too. Another reason to block JS. 8-)