Re: #904: Content on GET requirement strength

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

Received on Saturday, 17 July 2021 11:39:42 UTC