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

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

From: Annette Greiner <amgreiner@lbl.gov>
Date: Tue, 24 Sep 2019 11:26:40 -0700
To: "Lars G. Svensson" <lars.svensson@web.de>
Cc: DXWG WG List <public-dxwg-wg@w3.org>
Message-ID: <5cd2845f-b770-e85e-f346-8872b31d0516@lbl.gov>
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
Received on Tuesday, 24 September 2019 18:27:19 UTC

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