- From: Annette Greiner <amgreiner@lbl.gov>
- Date: Tue, 24 Sep 2019 14:18:31 -0700
- To: "Lars G. Svensson" <lars.svensson@web.de>
- Cc: DXWG WG List <public-dxwg-wg@w3.org>
- Message-ID: <be3c73a8-9ed5-34d0-e2ae-7d5da96aaf14@lbl.gov>
I don't even think QSA should be an option for priority as such, as it's
just an example implementation. Remember, we agreed that this subsection
was not normative for the specific app architecture. Other
implementations using URLs without query strings are possible and should
be allowed. I would call it URL-based profile negotiation and say that
in the case of conflict between URL-based and HTTP-header based
negotiation (the rare case where there is HTTP-header-based
configuration for a URL and the exact same URL is configured to be
handed off to a separate server process), the header configuration
should be ignored.
In this discussion, QSA represents a fallback mechanism, per our
charter. It seems backwards for the fallback to take precedence.
On 9/24/19 12:58 PM, Lars G. Svensson wrote:
>
> Would it help if we re-phrased this
>
> The order of precedence is QSA over HTTP - on the basis that the more
> exactly a URI points to a resource, the more likely it is that the
> agent intends to request that precise resource irrespective of which
> HTTP headers are sent with that request
>
> as
>
> If the request URI has a QSA part conforming to this specification,
> the order of precedence is QSA over HTTP - on the basis that the more
> exactly a URI points to a resource, the more likely it is that the
> agent intends to request that precise resource irrespective of which
> HTTP headers are sent with that request. Otherwise the content
> negotiation is done over http headers.
>
> ?
>
> Am 24.09.2019 um 20:26 schrieb Annette Greiner:
>>
>> I read the spec as saying that, "IF your application [meaning 'web
>> servers' and 'web applications'] can handle profile negotiation both
>> through http headers _and_ through QSA on URLs with the same path,
>> that application MUST use QSA if the request URI has a QSA part and
>> if it doesn't".
>>
>> On 9/24/19 3:08 AM, Lars G. Svensson wrote:
>>> Of course it's possible to implement that way, too.
>>> My question regarding your first scenario (header-based negotiation
>>> for paths without query string and QSA-based for other paths) is if
>>> the header-based negotiation really would be handled by the
>>> Apache/Nginx/... ("web server") or if it's all handled by one custom
>>> web application ("web application"). As I see it the resources must
>>> be static content if the "web server" is supposed to handle the
>>> content negotiation. So I assume that the "web application" would be
>>> used to parse the query string and find the appropriate static file.
>>> Do I understand that correctly? And of course it's no requirement
>>> that the "web application" handles header-based negotiation, and I
>>> don't think we've written that into the spec.
>>> In your second scenario, things seem even easier to me: If the
>>> profile is hard-coded into the URI, there is no need to perform
>>> profile negotiation at all. That is one of those cases that
>>> illustrate that "in doubt the URI trumps anything the request
>>> headers may say...".
>>> What we want to say in the specification is that "IF your
>>> application [meaning 'web servers' and 'web applications'] can
>>> handle profile negotiation both through http headers _and_ through
>>> QSA, that application MUST use QSA if the request URI has a QSA
>>> part". Is that your reading of the spec, too?
>>> If yes, do you agree with that reading? If no, is it because you
>>> think we say something else or because you think that approach is wrong?
>>> Best,
>>> Lars
>>> *Gesendet:* Montag, 23. September 2019 um 23:55 Uhr
>>> *Von:* "Annette Greiner" <amgreiner@lbl.gov>
>>> *An:* "Lars G. Svensson" <lars.svensson@web.de>
>>> *Cc:* "DXWG WG List" <public-dxwg-wg@w3.org>
>>> *Betreff:* Re: Moving conneg-by-ap to CR -- addressing concerns
>>> about the use of tokens
>>>
>>> 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
>>>
>> --
>> 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 Tuesday, 24 September 2019 21:19:04 UTC