- From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
- Date: Sat, 17 Jul 2021 13:39:13 +0200
- To: ietf-http-wg@w3.org
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