- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 17 Jul 2021 14:46:10 +0200
- To: ietf-http-wg@w3.org
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