Subject: HTTP PREVIEW method

From: "Soni L." <[email-masked]>
Date: Wed, 24 Nov 2021 14:08:54 -0300

It would be potentially useful to have an HTTP PREVIEW method. Consider for
example this mastodon issue:
https://github.com/mastodon/mastodon/issues/4486

Here's what happens when a wiki has to generate a full page:

1. Parse cookies
2. Get user data
3. Get page contents
4. Resolve "redlinks" (links within the wiki that refer to nonexistent
pages)
5. Create Table of Contents
6. Format full page
7. Etc

Here's what it'd do with an HTTP PREVIEW:

1. Get page contents
2. Trim it down to some arbitrary but small length
3. Create a simplified HTML that contains all the relevant data in the
<head>, and an empty <body>.

Given how much less work this would involve for the server, it could help a
lot with the above issue. As a bonus, HTTP PREVIEW could even be specced to
accept the #anchor part, providing for even better previews.

---

From: Evert Pot <[email-masked]>
Date: Wed, 24 Nov 2021 13:45:41 -0500

This sounds like this should be solved with either the 'Prefer: 
return=minimal' header, or (probably the better choice) 
content-negotation using Accept.

On 2021-11-24 12:08, Soni L. wrote:
> It would be potentially useful to have an HTTP PREVIEW method. 
> Consider for example this mastodon issue: 
> Given how much less work this would involve for the server, it could 
> help a lot with the above issue. As a bonus, HTTP PREVIEW could even 
> be specced to accept the #anchor part, providing for even better previews.
>

---

From: "Soni L." <[email-masked]>
Date: Wed, 24 Nov 2021 16:26:02 -0300

Using a new method has many benefits:

- Forbidding a bunch of headers you don't want in a preview request
(Cookies, DNT, etc).
- Explicitly not working with older software.
- Being able to throw in that #anchor tag and take it into account on the
preview (useful for Wikipedia article sections).
- Etc.

Aside from the thing about #anchor tags, these enable making the fast path
even faster, so it would use less resources.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 24 Nov 2021 20:54:42 +0100

> even faster, so it would use less resources.

But it prevents one from proposing anything in between. I mean, it's
all or nothing, and once someone starts to extend it using headers to
indicate various preferences, you'll end up with all the details in
the headers and two methods doing exactly the same thing. Plus having
a GET-like method would not allow you to use POST semantics for example,
and some could find it useful to upload an image to store it and retrieve
a preview of it in return (for example).

I too think that using header fields for this offers way more flexibility
than a dedicated method.

Regards,
Willy

---

From: "Soni L." <[email-masked]>
Date: Wed, 24 Nov 2021 17:36:26 -0300

The only acceptable alternative to making it a method would be making a
.well-known for this. That does have the issue of technically allowing POST
and all the existing headers (see below for why this is an issue). But it
would also be out of scope for http/this list, instead being covered under
(possibly?) the art list.

And no, you absolutely do not add the ability to carry preferences or POST
to it. Because if your website's preview cards need the target website to
handle those to work properly, you're doing preview cards wrong.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 24 Nov 2021 17:28:52 -0800

The essential aspect being missed here is that the view for a representation isn’t known by the server. It is almost always generated based on a combination of dynamically generated content from multiple resources and behavior selected by the user agent. A preview is therefore not an HTTP operation on a single resource, but rather a shared relationship among resources based on a primary initial target resource.

It is far easier to implement this as a separate resource on the server that is linked rel=preview from the target, directly per resource or via a URI template. The client can just GET that resource instead.

....Roy

> On Nov 24, 2021, at 12:39 PM, Soni L. <[email-masked]> wrote:
> 
> 
> The only acceptable alternative to making it a method would be making a .well-known for this. That does have the issue of technically allowing POST and all the existing headers (see below for why this is an issue). But it would also be out of scope for http/this list, instead being covered under (possibly?) the art list.
> 
> And no, you absolutely do not add the ability to carry preferences or POST to it. Because if your website's preview cards need the target website to handle those to work properly, you're doing preview cards wrong.
> 
>

---

From: "Soni L." <[email-masked]>
Date: Thu, 25 Nov 2021 00:18:24 -0300

Nope. That'll just lead to user agent sniffing, either to block the preview
cards entirely or to provide the fast-path OG metadata instead of having to
render the whole page anyway just for the thing to read the OG metadata (or
worse, a link to the OG metadata - which would add another request and more
overhead to the mix).

On Wed, Nov 24, 2021, 22:28 Roy T. Fielding <[email-masked]> wrote:

> The essential aspect being missed here is that the view for a
> representation isn’t known by the server. It is almost always generated
> based on a combination of dynamically generated content from multiple
> resources and behavior selected by the user agent. A preview is therefore
> not an HTTP operation on a single resource, but rather a shared
> relationship among resources based on a primary initial target resource.
>
> It is far easier to implement this as a separate resource on the server
> that is linked rel=preview from the target, directly per resource or via a
> URI template. The client can just GET that resource instead.
>
> ....Roy
>
>