- 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