-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed extension: content negotiation on /micropub interactions #28
Comments
I don't think most clients out there even declare an Accept header, but browsers commonly include |
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 |
@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 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. Request that does not perform content-negotiation
Requests that do:
Example media endpoint request:
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.The text was updated successfully, but these errors were encountered: