Taking full advantage of HTTP status codes The idea is to define all the common HTTP status codes and how they relate to blossom endpoints. This has kind of been an unspoken rule for too long that clients and servers should follow HTTP but its much better to actually define it in the blossom spec. #asknostr I would appropriate lots of feedback on this since its a big change. although its not a breaking change

Replies (2)

http 100 continue could be used to avoid round-trip head requests on PUT requests as it was intended to make the transmission and pre-check built into http . It also must be assumed that PUT requests are Idempotent which you sort of mention. Just thinking it might be worth making explicit (as standard http convention). While nice, I wouldn't expect servers to implement 507 as that could be a disclosure vulnerability. Chances are they'd ignore that, or return a 500 or a 503 instead (I suppose unless it's an authorized admin). I probably think of a few more things as I read on.
I was looking into the 100 status code but it looked like most HTTP clients or server frameworks didn't support manually managing that. most servers I've seen auto accept PUT uploads and most clients don't support waiting for the 100 response Id still like to look into it further though because its a cleaner solution than using the HEAD request.