Skip to content
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

Open
jamietanna opened this issue Jun 28, 2020 · 7 comments
Open

Comments

@jamietanna
Copy link

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
Copy link

vikanezrimaya commented Jul 12, 2020

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
Copy link

manton commented Jul 27, 2020

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
Copy link
Member

aaronpk commented Jul 27, 2020

@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
Copy link

manton commented Jul 27, 2020

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

@jamietanna
Copy link
Author

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

<html><body><p>The post has been created at <a href="https://www.staging.jvt.me/post#ewogICJkYXRlIiA6ICIyMDIwLTEwLTIwVDIwOjQ1OjA2LjUxNFoiLAogICJkZWxldGVkIiA6IGZhbHNlLAogICJoIiA6ICJoLWVudHJ5IiwKICAicHJvcGVydGllcyIgOiB7CiAgICAic3luZGljYXRpb24iIDogWyAiaHR0cHM6Ly9icmlkLmd5L3B1Ymxpc2gvdHdpdHRlciIgXSwKICAgICJwdWJsaXNoZWQiIDogWyAiMjAyMC0xMC0yMFQyMDo0NTowNi41MTRaIiBdLAogICAgImNhdGVnb3J5IiA6IFsgIm1vcnBoIiBdLAogICAgImNvbnRlbnQiIDogWyB7CiAgICAgICJodG1sIiA6ICIiLAogICAgICAidmFsdWUiIDogIkl0J3MgYmVlbiBhIGdyZWF0IFN1bmRheSBmb3IgPGEgaHJlZj1cIi90YWdzL21vcnBoL1wiPiNNb3JwaDwvYT4iCiAgICB9IF0KICB9LAogICJraW5kIiA6ICJub3RlcyIsCiAgInNsdWciIDogIjIwMjAvMTAvcWpkcXkiLAogICJ0YWdzIiA6IFsgIm1vcnBoIiBdLAogICJjbGllbnRfaWQiIDogImh0dHBzOi8vcXVpbGwucDNrLmlvLyIKfQ==">https://www.staging.jvt.me/post#ewogICJkYXRlIiA6ICIyMDIwLTEwLTIwVDIwOjQ1OjA2LjUxNFoiLAogICJkZWxldGVkIiA6IGZhbHNlLAogICJoIiA6ICJoLWVudHJ5IiwKICAicHJvcGVydGllcyIgOiB7CiAgICAic3luZGljYXRpb24iIDogWyAiaHR0cHM6Ly9icmlkLmd5L3B1Ymxpc2gvdHdpdHRlciIgXSwKICAgICJwdWJsaXNoZWQiIDogWyAiMjAyMC0xMC0yMFQyMDo0NTowNi41MTRaIiBdLAogICAgImNhdGVnb3J5IiA6IFsgIm1vcnBoIiBdLAogICAgImNvbnRlbnQiIDogWyB7CiAgICAgICJodG1sIiA6ICIiLAogICAgICAidmFsdWUiIDogIkl0J3MgYmVlbiBhIGdyZWF0IFN1bmRheSBmb3IgPGEgaHJlZj1cIi90YWdzL21vcnBoL1wiPiNNb3JwaDwvYT4iCiAgICB9IF0KICB9LAogICJraW5kIiA6ICJub3RlcyIsCiAgInNsdWciIDogIjIwMjAvMTAvcWpkcXkiLAogICJ0YWdzIiA6IFsgIm1vcnBoIiBdLAogICJjbGllbnRfaWQiIDogImh0dHBzOi8vcXVpbGwucDNrLmlvLyIKfQ==</a>.</p></body></html>
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

<html><body><p>Media <img src="https://media.staging.jvt.me/profile.png" /> was uploaded as <a href="https://media.staging.jvt.me/profile.png">https://media.staging.jvt.me/profile.png</a>.</p></body></html>

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
Copy link

manton commented Oct 21, 2020

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
Copy link

jalcine commented Oct 21, 2020

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants