Media endpoint should allow async processing

[nolith]

Micropub specs allows for a 202 Accepted answer for creating a new h-entry, as explained in 3.3.6 Response:

If the endpoint chooses to process the request asynchronously rather than creating and storing the post immediately, it MUST return an HTTP 202 Accepted status code, and MUST also return the Location header.

But the Media Endpoint only allows for a 201 Created answer, as explained in 3.6.4 Response.

I propose we extend the usage of 202 Accepted to the media endpoint to make static site generators compliant with the spec.

Just to give an example of my setup: my blog is statically generated in CI, and my micropub server is a stateless container that converts incoming requests into git commits, those commits in turn triggers my CI and the blog is published.

With such enviroment it will be not possible to make the image immediately available.

(Originally published at: https://l0g.in/5EKG00)

[manton]

I wonder if not allowing 202 in the spec was intentional. For example, I can image an app that would upload a photo and then need to show a preview with that URL right away, or download the URL to get other info such as final dimensions if the server resized it. (This doesn't affect me, so I don't want to make too big a deal about it… Mostly curious.)

[capjamesg]

Like you, @nolith, my site is also statically generated so I cannot serve assets immediately without my adding a way of hosting images external to my blog.

I agree with @manton that an application might want to preview a URL but I think there is room for both a 202 and 201 response to be given. Thus, clients that support previewing would want to send a 201 response and clients that do not would send a 202 response.

[capjamesg]

One issue with allowing 202 Accepted responses is that this might mean content is served without an image in some cases (for instance, where an image is slower to upload than the post). This would be the case for my setup (as uploading photos and posts happen in separate commits as the media endpoint is independent from the rest of my Micropub endpoint) but the gap has thus far been so small I have not noticed.

[rockorager]

This mostly comes up with git workflows, so would it be wrong to respond 201 as soon as your commit is successful, even if the build process hasn't happened? The URL should still be known, so you can respond with a 201 and Location, the image was successfully committed to the repo. A client that tries to fetch the image will get a 404 though, but only until the CI process is completed.

[capjamesg]

Yeah. That's the workflow I go through:

1. Create a post with my Micropub client.
2. Media endpoint processes and saves image then commits the image. The URL of the image is known at this stage and is sent back in a location header so it can be paired with alt text in the post content as per the spec.
3. Server processes request.
4. Server creates commit on GitHub with post.
5. About two minutes passes in build.
6. The post and image are visible on my site.