Re: #904: Content on GET requirement strength

Rafal Pietrak <cookie.rp@ztk-rp.eu> Sat, 17 July 2021 11:42 UTC

Resent-Date: Sat, 17 Jul 2021 11:39:44 +0000
Resent-Message-Id: <E1m4ifY-0000dR-Hy@lyra.w3.org>
To: ietf-http-wg@w3.org
References: <BFB50EB9-90E2-44B0-B469-4FBFA0488BFE@mnot.net> <BLAPR22MB2259BDE901088D82A1033F45DA119@BLAPR22MB2259.namprd22.prod.outlook.com> <9D46B333-D2F1-4D1D-9BE3-D6B701167B70@tzi.org> <CAF8qwaDXjHZ6cQO5512VsDi7ZRT0wq5h3NQWuR4x67Fq_Qn9Mg@mail.gmail.com> <CAEdRHi7iH060t0xhOtuiEj2vApfD5KRu=v-6LBErp+6v+z=pyQ@mail.gmail.com> <106CAD9F-66C1-4852-892C-F20F8B44B911@tzi.org>
From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
Message-ID: <2165ab6d-5faa-b962-896b-16e0e18958bf@ztk-rp.eu>
Date: Sat, 17 Jul 2021 13:39:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <106CAD9F-66C1-4852-892C-F20F8B44B911@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=cookie.rp@ztk-rp.eu; remoteip=::ffff:193.239.82.149; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl;
Received-SPF: pass client-ip=83.17.179.219; envelope-from=cookie.rp@ztk-rp.eu; helo=sm.strop.com.pl
Subject: Re: #904: Content on GET requirement strength
Archived-At: <https://www.w3.org/mid/2165ab6d-5faa-b962-896b-16e0e18958bf@ztk-rp.eu>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hello everybody,

Pls forgive me cutting in, where I'm not particularly competent, but
I've checked the link below, and read it from a perspective of a
"simple" home-page web writer. The comments bellow come from reading it
specifically from such perspective (i.e: what it gives web-page-authors).

The draft seam to define SEARCH as "something" that HTTP server may
receive "from the wild". When reading the proposal from
"home-page-author" perspective, one MUST assume, that all the SEARCH
requests will "get back" to the server as a result of interpretation of
just received by the browser a "home-page". IMHO this perspective is
missing from the draft.

I admit, that when fixed (as below), the SEARCH method could provide
functionality I was attempting to achieve with my cookie-draft.

W dniu 17.07.2021 o 11:50, Carsten Bormann pisze:
> On 2021-07-16, at 22:43, Asbjørn Ulsberg <asbjorn@ulsberg.no> wrote:
>>
>> To
>> accommodate these use cases, an I-D for a safe method with body has
>> been initiated:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
>>
>> With such a method in the implementer's toolbox, I'm pretty certain a
>> MUST NOT requirement would be easy to swallow.
> 
> Indeed.
> 

From 'home-page-writer' perspective, we assume, that the entire
selection of possible SEARCH requests, that a client browser could
submit to that server is provided to that browser by that server on the
just retrieved home-page (html-home-page).

If so, the questions are:
1. will it be possible to send to the browsers a "home-page" with some
of the <form method="POST"> turned into <form method="SEARCH">? It looks
like YES, but I'm not quite sure. So, at least a "none nominative"
example would be nice to have.
2. will it be possible to change some (or all, if provision just "some"
is unreasonable difficult) of the "<a href=''>", "<img src=>", "<link>",
etc, etc, from launching a GET requests, into launchinig a SEARCH
requests instead? This is not addressed by the draft, yet IMHO it would
be nice to have.
3. the draft mentions 'accept-search' being used by the server to
indicate it can accept SEARCH method. But from (1) and (2) above, it's
equally important, that the browser is able to notify server, that the
web-page returned can contain SEARCH requests ... like in <form
methos="SEARCH"> in (1) above. So, "accept-search" should also be send
to servers by complying browsers.

Then again, when server receives "accept-search" it may request browser
to turn "all the possible" href/src/source links from GET into SEARCH.
something like "meta-search" for the <HEAD> could do that.

That "meta-search" also could supplement SEARCH triggered by "a href"
(or others) with additional data.

the SEARCH draft mentions, that processing of SEARCH by the server will
not change state of the server. From those words I was missing an
emphesise, that in consequence, web browser submitting a SEARCH should
not alert user like they do when user requests "page-refresh", while
that page arrived as a response to POST request. Such clearification
would be desirable

I think there may be a problem with 3xxx redirect response as defined in
current version of the draft: "alterative URI from which the search
results can be retrieved using an HTTP GET request".

The problem may be at the point where one MUST change method from SEARCH
to GET. This may prove difficult when not all the SEARCH params fit into
GET request. So, such change request should probably be returned by the
server only under specific circumstances, and so as specific/uniq
redirect code; while "simple redirection" should NOT change methods
(SEARCH->GET).

-- 
Rafał Pietrak

#904: Content on GET requirement strength Mark Nottingham
RE: #904: Content on GET requirement strength Mike Bishop
Re: #904: Content on GET requirement strength Carsten Bormann
Re: #904: Content on GET requirement strength David Benjamin
Re: #904: Content on GET requirement strength Julian Reschke
Re: #904: Content on GET requirement strength Willy Tarreau
Re: #904: Content on GET requirement strength Asbjørn Ulsberg
Re: #904: Content on GET requirement strength Carsten Bormann
Re: #904: Content on GET requirement strength Rafal Pietrak
SEARCH Julian Reschke
Re: SEARCH Rafal Pietrak
Re: #904: Content on GET requirement strength Mark Nottingham
Re: #904: Content on GET requirement strength Amos Jeffries
Re: #904: Content on GET requirement strength Willy Tarreau