- From: Annette Greiner <amgreiner@lbl.gov>
- Date: Mon, 23 Sep 2019 14:55:08 -0700
- To: "Lars G. Svensson" <lars.svensson@web.de>
- Cc: DXWG WG List <public-dxwg-wg@w3.org>
- Message-ID: <7f53d958-0de6-22ae-38f2-dc0c53923d2a@lbl.gov>
My thought here is that it could prove worthwhile to use a combination of both. For example, requests for a given path without a query string could be handled by header-based negotiation while those that have a query string are sent to an application. That allows development for both types of request. It needn't be seen as a conflict where one or the other handling needs to win out over the other, because the URLs are technically not the same. That is, it should be possible for a request that has no QSA to be negotiated by header and a similar request that simply adds a QSA string to be handled by a web application. Requiring that the request without a QSA be handled by the application seems wrong and unnecessary. It is also conceivable that one could build a web application that uses headers for profile negotiation but also uses query strings for something else. Re the binary theory of handling requests, things are a little more complicated. There is also the case where the path without query string determines the profile used for the data returned (e.g., http://datasite.org/path/to/dataset/byprofile/dcat-ap vs. http://datasite.org/path/to/dataset/byprofile/dcat. A custom web application can be created without the use of query strings. A web server can be configured to send a URL that has no query string for processing by a custom web application. -Annette On 9/22/19 9:35 PM, Lars G. Svensson wrote: > > My take is that content negotiation would always be handled _either_ > bei the web server (Apache) _or_ by a custom web application. Never by > both (for the same path, that is...). > > So if there is static content the web server may handle that doing all > sorts of negotiation (media type, language, data profile) on http > headers only. If it's dynamic content you need a custom web > application that can be a CGI script, a PHP application or anything > else where the web server acts as a reverse proxy. That web > application can handle either http headers, query strings or both, and > the server (acting as a reverse proxy) only passes the request URL and > the headers through without doing any kind of negotiation. > > I think it would be extremely unhandly to have a system where the > header negotiation is done by the web server and the QSA negotiation > by the web application, particularly since there are often different > teams managing the server and the web applications. > > Best, > > Lars > > Am 20.09.2019 um 18:46 schrieb Annette Greiner: >> >> Another angle on this that occurred to me after responding is the >> behavior expected when the content negotiation is handled by an API >> that doesn't use query strings. The URLs would then be amenable to >> normal content negotiation, and the web server would have no way to >> know that there was an issue. It would have no choice but to handle >> the negotiation. >> >> What happens now if you try to configure conneg for a URL with a >> query string? I've not found any documentation addressing that case. >> We may have to experiment. >> >> -Annette >> >> On 9/19/19 9:47 PM, Rob Atkinson wrote: >>> I think the conflict case is better handled by defining the simplest >>> behaviour (which i think the spec does) and leave it to >>> implementations to sort out how to implement it. >>> >>> just passing QSA and headers to a Web Application is a very simple >>> way to implement - so concerns about how to finesse a particular >>> HTTP server to do some or part of this should be left out of scope. >>> >>> If we need to make this more obvious somehow then an editorial >>> change to improve wording can be considered. >>> >>> 1022 seems like a resolution would be an editorial change to ram >>> home to people with only one perspective that profiles can apply to >>> both behaviour and data. People familiar with profiles of services >>> may need to have it explained that data conforms to specifications >>> too, and vice versa. - but its only an issue of optimising >>> explanatory text to the extent possible with the inputs offered. >>> >>> >>> >>> >>> >>> On Fri, 20 Sep 2019 at 11:29, Annette Greiner <amgreiner@lbl.gov >>> <mailto:amgreiner@lbl.gov>> wrote: >>> >>> Thanks, Lars, for pulling all this together. I was out for a >>> couple of >>> key weeks on holiday and have been working through the 700 >>> emails that >>> ended up in my w3c mail folder during that time. So, I'm sorry that >>> these suggestions seem late, though they did seem to be under >>> discussion >>> by others pretty recently. >>> >>> My vote was to wait a bit before review and freezing, so that the >>> editors would have a chance to finish up the discussion about the >>> various issues still simmering and so that I would be able then >>> to vote >>> yes for moving to CR. When it became evident that there is no >>> willingness to wait on the freeze due to schedule constraints, I >>> switched to an abstention so as not to block things. >>> >>> Re the use of tokens, I support them for the case of a query >>> string but >>> not elsewhere. Removing all mention of them as identifiers >>> satisfies one >>> concern about how they are used. My other concern is just to >>> keep things >>> as simple as possible and avoid creating new required (if you use >>> tokens) headers. I saw the conversation about where the mapping >>> from >>> token to URI should appear, and it occurred to me that that really >>> doesn't need to appear in headers if it appears in the returned >>> list of >>> options itself. That takes care of letting the client know what >>> token to >>> use in a query to that server. The preferred token is something >>> different, which I think would belong in the profile itself. As >>> long as >>> header-based negotiation can be done entirely with URIs, I think >>> the >>> role of tokens can be quite limited. We do need to offer a mapping >>> between tokens and the profiles of datasets returned by a given >>> server, >>> but it doesn't need to be in headers. Technically, we wouldn't >>> even need >>> to do a mapping between tokens and URIs, but I think it would be >>> best >>> practice to do it anyway. >>> >>> Re the handling of conflicts, I think we need to offer guidance to >>> developers of general-purpose server software that they can follow. >>> Since they already support content negotiation for media types and >>> languages, I would expect them to at least consider supporting >>> conneg >>> for profiles. I don't think we should ask them to parse query >>> strings. >>> There are a few other options, though. We could ask them to drop >>> content >>> negotiation if there is a query string present, and to send the >>> request >>> forward as if the conneg directives for the URL were not >>> present. That >>> would have the effect of preventing any future innovative uses >>> of query >>> strings for negotiated content, and it would do the wrong thing >>> when a >>> user adds a query string by accident. We could say the server >>> should >>> drop the query string and just do the content negotiation as if it >>> weren't there. This handles the user error case nicely but >>> probably does >>> the wrong thing for the case of misconfiguration half the time, >>> and it >>> again prevents innovative use of the combination. Or the server >>> could >>> take a kind of literal approach and consider the query string as >>> part of >>> the mapping for the negotiation. That is, one could actually >>> configure >>> the server to handle negotiation for a URL with a specific query >>> string >>> and have it negotiate specifically for that case. >>> >>> There are a lot of cases here now that I think it all through. >>> Here is >>> what I would expect for the literalist approach: >>> >>> config request behavior >>> >>> conneg directive for URL w/out query string* query string >>> present** >>> pass to app >>> conneg directive for URL w/out query string query string not >>> present handle conneg (no conflict) >>> conneg directive for URL w/query string query string present >>> handle >>> conneg >>> conneg directive for URL w/query string query string not present >>> serve from file system or pass to app >>> no matching directive for URL query string not present >>> serve from >>> file system or pass to app (no conflict) >>> no matching directive for URL query string present serve from >>> file system or pass to app (no conflict) >>> no matching directive for URL w/query string but directive for >>> URL w/out >>> query string query string present pass to app >>> no matching directive for URL w/out query string but directive >>> for URL >>> w/query string query string not present handle conneg >>> conneg directive for URL w/query string and URL w/out query string >>> query string present handle conneg for URL w/query string >>> conneg directive for URL w/query string and URL w/out query string >>> query string not present handle conneg for URL w/out query string >>> >>> *there is a directive in the server configuration that maps a >>> URL that >>> has no query string to a set of options. >>> **the client issues a request to the server for a URL that includes >>> query string arguments. >>> >>> >>> Here is the approach where QSA always wins: >>> >>> config request behavior >>> >>> conneg directive for URL w/out query string* query string >>> present** >>> pass to app >>> conneg directive for URL w/out query string query string not >>> present handle conneg (no conflict) >>> -conneg directive for URL w/query string query string >>> present pass >>> to app >>> conneg directive for URL w/query string query string not present >>> serve from file system or pass to app >>> no matching directive for URL query string not present >>> serve from >>> file system or pass to app (no conflict) >>> no matching directive for URL query string present serve from >>> file system or pass to app (no conflict) >>> no matching directive for URL w/query string but directive for >>> URL w/out >>> query string query string present pass to app >>> -no matching directive for URL w/out query string but directive >>> for URL >>> w/query string query string not present pass to app >>> -conneg directive for URL w/query string and URL w/out query string >>> query string present pass to app >>> -conneg directive for URL w/query string and URL w/out query string >>> query string not present pas to app >>> >>> -differs from literalist approach >>> >>> I also have a comment on #1022 that hasn't been resolved, along >>> with Isaac. >>> >>> -Annette >>> >>> On 9/18/19 8:39 AM, lars.svensson@web.de >>> <mailto:lars.svensson@web.de> wrote: >>> > Dear Annette, >>> > >>> > I couldn't attend the DXWG meeting yesterday but read the >>> minutes [0]. From what I understand, you oppose to moving >>> conneg-by-ap to CR (first voting -1, then 0) as you "think there >>> are open conversations issues". >>> > >>> > You have been very helpful in shaping the work of the conneg >>> deliverable and have provided valuable feedback and as one of >>> the editors I'm contacting you to see if there is chance to >>> resolve those open issues so that we can move the specification >>> forward to CR. >>> > >>> > My understanding is that your main points of critique are >>> about the use of tokens. That indeed seems to be the most >>> controversially discussed feature in the spec with comments >>> ranging from "tokens are completely unnecessary and their use >>> should be discouraged" to "tokens are an essential feature of >>> deployed APIs and we need to standardise their use in order to >>> improve interoperability". >>> > >>> > What I haven't understood yet is exactly where your position >>> on this is. From reading your comments in #453, #501 and #505, I >>> get the impression that you are not completely opposed to the >>> use of tokens but have concerns regarding how far it is possible >>> to give normative instructions on how to use them. >>> > >>> > In #453 (Consider use of adms:identifier instead of >>> prof:token) you say that the spec (in this case prof:) should >>> not claim that tokens are identifiers [1]. The editors of that >>> spec have offered to change the definition of prof:hasToken to >>> accommodate that [2]. Would that resolve that issue for you? >>> > >>> > In #501 (Registration of target attribute "profile" for the >>> Link-Header) I read your position to be that even if tokens in >>> some cases can be used to specify (or name) a profile, it is >>> unnecessary to provide a method to convey token/URI mappings in >>> http headers since that information can be transported in a >>> profile description (e. g. a human-readable document or an RDF >>> graph using prof:). In #501 you say that you have "not seen >>> discussion that convinces me that we really need token mappings" >>> and that we've moved away from the assumption that "a thing [sc. >>> a token] has the same standing as a URI and can be used in the >>> same ways" [3]. As seen in #290 [4], there is a plenary-approved >>> requirement for this kind of mapping and given that there has >>> been much discussion in that issue over the last four weeks I'm >>> surprised that you voice your concerns so late in the process. >>> It might be that we have moved away from the assumption that >>> tokens have the same standing as URIs but I don't see how that >>> renders tokens – or a machine-readable mapping from tokens to >>> URIs – useless. Can you expand a bit on exactly what is your >>> concern here? >>> > >>> > In #505 (Specify the realisation order of precedence for >>> conflicting profile negotiation situations) I read your concern >>> to be that the conneg-by-ap spec would force _all_ http server >>> implementers to change their software to be compliant [5]. My >>> personal understanding of the spec's intention is that the order >>> of precedence is only relevant for server implementations that >>> implement _both_ QSA negotiation _and_ http negotiation as >>> specified in conneg-by-ap. If you agree with that I'd be happy >>> to discuss text edits that clarify that (assuming that the other >>> editors would agree...). >>> > >>> > I'm looking forward to your views on this and hope that we can >>> have it resolved in time for the vote. >>> > >>> > [0] https://www.w3.org/2019/09/17-dxwg-minutes >>> > [1] https://github.com/w3c/dxwg/issues/453#issuecomment-532420615 >>> > [2] https://github.com/w3c/dxwg/issues/453#issuecomment-532442529 >>> > [3] https://github.com/w3c/dxwg/issues/501#issuecomment-532436539 >>> > [4] https://github.com/w3c/dxwg/issues/290 >>> > [5] https://github.com/w3c/dxwg/issues/505#issuecomment-532441285 >>> > >>> > Best, >>> > >>> > Lars >>> > >>> -- >>> Annette Greiner (she) >>> NERSC Data and Analytics Services >>> Lawrence Berkeley National Laboratory >>> >>> >>> >> -- >> Annette Greiner (she) >> NERSC Data and Analytics Services >> Lawrence Berkeley National Laboratory >> -- Annette Greiner (she) NERSC Data and Analytics Services Lawrence Berkeley National Laboratory
Received on Monday, 23 September 2019 21:55:44 UTC