Re: HTTP PREVIEW method

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