Open jamietanna opened 4 years ago
I don't think most clients out there even declare an Accept header, but browsers commonly include text/html
here. So, my proposal: add a clause that specifies that if Accept header contains the string text/html
, the Micropub endpoint MAY reply with an HTML page describing the status of the post instead of the Location
header. Such page, if present, SHOULD incude the URL that would be included in the Location
header otherwise.
My concern with this is that we already have 2 ways to create posts with Micropub: form-encoded and JSON. It feels like this would be adding a 3rd way to create posts. I know the request parameters would be the same, but handling Accept
and coming up with useful HTML to return would add a lot of complexity to servers.
@manton this is talking specifically about the response, not the request. In the case of a browser being a Micropub client via an HTML form, that would use the existing form-encoded request.
Right now the response body of the Micropub request is not defined at all. That means servers are free to do whatever. Some of them currently do not include any response body, some of them return a JSON object with the post's URL (duplicating the Location
header), and some may return HTML (either the post that was just created, or an HTML redirect to the post).
In general, fewer options leads to stronger and easier implementations, so I would really question whether adding this option would provide any real value.
@aaronpk Yep, I get it. I think we're saying the same thing, but you said it more completely than I did. 🙂
I have had this implemented on my Micropub server for a month or so now, and would like to comment on what a great quality-of-life improvement it's had.
As my personal Micropub client (among others) publishes straight to the Micropub endpoint via an HTML form, it means that using a browser allows me to get a richer response.
But I have seen no issues with clients seeing this as an issue.
Media was uploaded as https://media.staging.jvt.me/profile.png.
```Note that the response body is not marked up in any way as to make it easier for a client to consume it. It's purely as a way to provide some user-focussed body.
That's good it's working for you, but I still don't thinks this needs to be implemented in any other servers. It doesn't solve a problem that existing Micropub clients have because they already do a POST either between servers, from a native client app, or from a web browser using JavaScript.
I agree with @manton’s comment. The only case I can see for more advanced responses would be if it was expecting it in some alternative format like ActivityStreams because a client could represent those posts inline more easily than Microformats2, for example.
(Originally published at: https://v2.jacky.wtf/post/61fdc2df-4aea-4670-9b64-10c114471af2)
I think it would be quite useful to standardise the way a Micropub server handles being submitted by a form on a web page, rather than through an API call, as it'd allow sending the usual 201/202 with
Location
header if not requesting HTML, but otherwise provide an HTML response, maybe even the page itself, if not.We should be able to do this based on
Accept
header based content negotiation.