W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

Re: Moving conneg-by-ap to CR -- addressing concerns about the use of tokens

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:58 UTC