micropub.rocks
micropub.rocks copied to clipboard
aaronpk
70x: Accept 202 responses
The spec defines 202 status codes for asynchronous media uploads, so test 700, 701, and 702 should allow it.
Additionally, I would suggest that all of the post creation tests (10X, 20X, 30X) should all also respect an HTTP 202 response, and not try to load the returned location immediately.
I'm not a PHP developer, but would a pull request be helpful to move this along? ;-)
I don't actually see where in the spec it allows a 202 in response to the media endpoint. https://www.w3.org/TR/micropub/#response-3 That seems to clearly say that only 201 is allowed.
Do you have a case where you would rather respond with an asynchronous status code?
@skpy the creation tests do already recognize an HTTP 202 response as a success. I did find a problem which is that if the endpoint returns a 3xx response, the HTTP client was following the redirect and was showing the response from loading the URL rather than showing the response from the micropub endpoint. I've fixed that in https://github.com/aaronpk/micropub.rocks/commit/cefd9aa48bd7d97a42bc12595bb8bd6c2a068ef5
👍 I don't recall now why I might have wanted an asynchronous process. Maybe it was so that site generation using a tool like Hugo or Jekyll could be done on some schedule. It wasn't enough of a problem to stick in my head, so it must not have been super important.
Tests 300 and 301 allow for HTTP 202 ;-)
Why I want it: my endpoint is meant for static sites: it writes to a file store, which in turn trigger a site build-and-deploy process. I cannot make this synchronous, and my (admittedly dated) understanding of HTTP 201 is that it indicates the resource will be immediately available at Location.
@skpy to be clear, the micropub endpoint tests have always allowed an async response using 202. It's just the media endpoint response in question here.
@gerwitz are you using the same static site build process as your media endpoint? Tests 300 and 301 are testing the micropub endpoint, not the media endpoint, so that isn't the same as the 7xx tests.
Indeed, same process for posts and media.
(I am trying to enable any SSG user to adopt Micropub.)
I am running across this same issue too. I think it’s largely because there may sometimes be a discrepancy between where files and media are stored, and where they are accessible to the public.
Indeed, when I began building my endpoint, I assumed that given the endpoint was interfacing with where files are stored, it should return statuses and locations based on that information (in my case this would be 202 and the location of a file on a GitHub repo). But then I realised that the spec asks that endpoints return details relating to the published location (makes sense)… but there’s not always a 1:1 relationship between where a file has been saved, and where it is (more) publicly available.
This discrepancy is highlighted by those like myself @gerwitz who are using static site generators, saving files to places like GitHub, and then via tools like Netlify post-publishing the site in a separate flow. I wonder if there’s a way to better account for this use case?
