Re: HTTP PREVIEW method

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 <fielding@gbiv.com> 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
>
>
> On Nov 24, 2021, at 12:39 PM, Soni L. <fakedme+http@gmail.com> 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.
>
>
> On Wed, Nov 24, 2021, 16:54 Willy Tarreau <w@1wt.eu> wrote:
>
>> On Wed, Nov 24, 2021 at 04:26:02PM -0300, Soni L. wrote:
>> > 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.
>>
>> 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
>>
>