If the first one is OPTION, would that be a bug? Would the right design principle be to do it once per endpoint and then cache it for future requests?
I’m really curious cause I don’t know how this usually works…
Comment on Quick video demonstrating that lemmy.world sends every activity out twice
bamboo@lemmy.blahaj.zone 7 months ago
Are you able to include the HTTP Method being called and the amount of data transferred per request? It’s possible that the first request is an OPTION request and then the second request is a POST.
If you can see the amount of data transferred, then you can have some more indication that double the requests are being sent and quantity the bandwidth impact at least.
If the first one is OPTION, would that be a bug? Would the right design principle be to do it once per endpoint and then cache it for future requests?
I’m really curious cause I don’t know how this usually works…
That’s pretty standard with most libraries
I’ve never really seen this in (Java/Rust/PHP) backend personally, only in client-side JS (the CORS preflight).
It’s a security feature for browsers doing calls (checking the CORS headers before actually calling the endpoint), but for backends the only place it makes sense is if you’re implementing something like webhooks, to validate the (user submitted) endpoint.
Ok so my assumptions were right. Interesting…
freamon@lemmy.world 7 months ago
They’ll all POST requests. I trimmed it out of the log for space, but the first 6 requests on the video looked like (nginx shows the data amount for GET, but not POST):
If I was running Lemmy, every second line would say 400, from it rejecting it as a duplicate. In terms of bandwidth, every line represents a full JSON, so I guess it’s about 2K minimum for the standard cruft, plus however much for the actual contents of comment (the comment replying to this would’ve been 8K)
My server just took the requests and dumped the bodies out to a file, and then a script was outputting the object.id, object.type and object.actor into /tmp/demo.txt (which is another confirmation that they were POST requests, of course)