indieweb / micropub-extensions

Issue tracking for Micropub extensions
https://indieweb.org/Micropub-extensions
10 stars 0 forks source link

Proposed extension: content negotiation on /micropub interactions #28

Open jamietanna opened 4 years ago

jamietanna commented 4 years ago

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.

vikanezrimaya commented 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.

manton commented 4 years ago

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.

aaronpk commented 4 years ago

@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.

manton commented 4 years ago

@aaronpk Yep, I get it. I think we're saying the same thing, but you said it more completely than I did. 🙂

jamietanna commented 4 years ago

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 ``` % curl https://www-api.staging.jvt.me/micropub -i -H 'Authorization: Bearer ...' -d h=entry -d "content=It's been a great Sunday for #Morph" HTTP/1.1 202 Accepted Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Length: 0 Date: Tue, 20 Oct 2020 20:44:57 GMT Expires: 0 Location: https://www.staging.jvt.me/post#ewogICJkYXRlIiA6ICIyMDIwLTEwLTIwVDIwOjQ0OjU3LjkwNloiLAogICJkZWxldGVkIiA6IGZhbHNlLAogICJoIiA6ICJoLWVudHJ5IiwKICAicHJvcGVydGllcyIgOiB7CiAgICAic3luZGljYXRpb24iIDogWyAiaHR0cHM6Ly9icmlkLmd5L3B1Ymxpc2gvdHdpdHRlciIgXSwKICAgICJwdWJsaXNoZWQiIDogWyAiMjAyMC0xMC0yMFQyMDo0NDo1Ny45MDZaIiBdLAogICAgImNhdGVnb3J5IiA6IFsgIm1vcnBoIiBdLAogICAgImNvbnRlbnQiIDogWyB7CiAgICAgICJodG1sIiA6ICIiLAogICAgICAidmFsdWUiIDogIkl0J3MgYmVlbiBhIGdyZWF0IFN1bmRheSBmb3IgPGEgaHJlZj1cIi90YWdzL21vcnBoL1wiPiNNb3JwaDwvYT4iCiAgICB9IF0KICB9LAogICJraW5kIiA6ICJub3RlcyIsCiAgInNsdWciIDogIjIwMjAvMTAvMHFqMWgiLAogICJ0YWdzIiA6IFsgIm1vcnBoIiBdLAogICJjbGllbnRfaWQiIDogImh0dHBzOi8vcXVpbGwucDNrLmlvLyIKfQ== Pragma: no-cache Server: Caddy X-Content-Type-Options: nosniff X-Frame-Options: DENY X-Xss-Protection: 1; mode=block ```
Requests that do: ``` % curl https://www-api.staging.jvt.me/micropub -i -H 'Authorization: Bearer ...' -d h=entry -d "content=It's been a great Sunday for #Morph" -H 'accept: text/html' HTTP/1.1 200 OK Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Length: 1446 Content-Type: text/html;charset=UTF-8 Date: Tue, 20 Oct 2020 20:45:06 GMT Expires: 0 Pragma: no-cache Server: Caddy X-Content-Type-Options: nosniff X-Frame-Options: DENY X-Xss-Protection: 1; mode=block

The post has been created at https://www.staging.jvt.me/post#ewogICJkYXRlIiA6ICIyMDIwLTEwLTIwVDIwOjQ1OjA2LjUxNFoiLAogICJkZWxldGVkIiA6IGZhbHNlLAogICJoIiA6ICJoLWVudHJ5IiwKICAicHJvcGVydGllcyIgOiB7CiAgICAic3luZGljYXRpb24iIDogWyAiaHR0cHM6Ly9icmlkLmd5L3B1Ymxpc2gvdHdpdHRlciIgXSwKICAgICJwdWJsaXNoZWQiIDogWyAiMjAyMC0xMC0yMFQyMDo0NTowNi41MTRaIiBdLAogICAgImNhdGVnb3J5IiA6IFsgIm1vcnBoIiBdLAogICAgImNvbnRlbnQiIDogWyB7CiAgICAgICJodG1sIiA6ICIiLAogICAgICAidmFsdWUiIDogIkl0J3MgYmVlbiBhIGdyZWF0IFN1bmRheSBmb3IgPGEgaHJlZj1cIi90YWdzL21vcnBoL1wiPiNNb3JwaDwvYT4iCiAgICB9IF0KICB9LAogICJraW5kIiA6ICJub3RlcyIsCiAgInNsdWciIDogIjIwMjAvMTAvcWpkcXkiLAogICJ0YWdzIiA6IFsgIm1vcnBoIiBdLAogICJjbGllbnRfaWQiIDogImh0dHBzOi8vcXVpbGwucDNrLmlvLyIKfQ==.

```
Example media endpoint request: ``` % curl https://www-api.staging.jvt.me/micropub/media -i -H 'Authorization: Bearer ...' -F file=@static/img/profile.png -H 'accept: text/html' HTTP/1.1 200 OK Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Length: 206 Content-Type: text/html;charset=UTF-8 Date: Tue, 20 Oct 2020 20:51:05 GMT Expires: 0 Pragma: no-cache Server: Caddy X-Content-Type-Options: nosniff X-Frame-Options: DENY X-Xss-Protection: 1; mode=block

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.

manton commented 4 years ago

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.

jalcine commented 4 years ago

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)