Re: SEARCH

Hi,

W dniu 17.07.2021 o 14:46, Julian Reschke pisze:
> Am 17.07.2021 um 13:39 schrieb Rafal Pietrak:
[------------]
>> just received by the browser a "home-page". IMHO this perspective is
>> missing from the draft.
> 
> It's not the only perspective.

That's for sure.

I've only got an impression, that this particular perspective was not

[-------------]
>> 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.
> 
> That would require a change from the HTML spec.

OK. Somehow I've assumed, that GET/POST and HTML-FORM are "kind-of
inter-woven" with each other. Probably I've got the assumption a bit too
far.

Still, if there pops up another transport method (HTTP/SEARCH). It would
be nice for the payload specs to follow.

> 
>> 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.
> 
> No. GET remains the primary method for information retrieval.

Yes. But when another doors open, why keep it half closed. The SEARCH as
it is, could be beneficial for some, but with little extention it may be
far better for much more of us.

I just ment the above - see the potential.

[------------]
>> 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.
> 
> Why would you want that?

to be able to supplement more parameters to GET (by replacing it behind
screens  with a SEARCH) with additional information (required for
successfully fetching the href/src link), without javascripting.

I can imagine, that it could also be a place to explicitly declare "on
the page" the list of cookies that this server expects with
GET/POST/SEARCH from this page. Such far reaching modification could
allow server some additional control over cookies at client browser
without javascritp ever touching them. ... like server saying: "from
this page, send only this list of cookies, no other".

I'm stressing "additional information", because:
1. SEARCH looks like a method with "capacity" similar to the POST method
2. I would expect GET getting obsoleted in time, with such capable
contender as SEARCH. (despite the fact, that it's currently the "primary
means")

[--------------]
>> 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).
> 
> A server would only do that if it actually can define a URI for the
> final SEARCH result.

the problem is (can be) at the client side. I'm assuming here, that
initial SEARCH was originally "cooked" like a POST with large list of
parameters in multipart body. Now, if the client gets a redirect to GET,
all that parameters must end up at GET argument line. I expect, that
could be a problem in some corner cases.

-- 
Rafał Pietrak

Received on Saturday, 17 July 2021 13:49:28 UTC