Re: HTTP PREVIEW method

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
>