W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

SEARCH

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 17 Jul 2021 14:46:10 +0200
To: ietf-http-wg@w3.org
Message-ID: <d38ac21a-a901-5527-d7d0-a35b4a2b2e89@gmx.de>
Am 17.07.2021 um 13:39 schrieb Rafal Pietrak:
> 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.

It's not the only perspective.

> ...
>>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.

That would require a change from the HTML spec.

> 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.

> 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.

Actually, the signal for the *method* is the "Allow" response header
field. "accept-search" would be about the supported formats.

> 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?

> 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

That follows from the defintion of being a "safe" method.

> 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.

Best regards, Julian
Received on Saturday, 17 July 2021 12:46:26 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 17 July 2021 12:46:28 UTC