-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QUERY: Headers for URI options? #2899
Comments
I don't get the use case yet. A server can provide a GETtable URI in the response, but does not have to. How it does that should be left to the server. Exactly why would a client care? |
We can probably expect the I can see users caring. I would care, for example. URIs, including q-params, are among the most important developments in the Internet in the past 40 years! Users intuitively understand that q-params in URIs are "editable", and they do in fact edit them. Not just knowledgeable users like you or me, but I'm sure you know -I do!- people who are not so knowledgeable who edit q-params in URIs. But it's also true that not every complex query can be encoded into the URI. URI length limits and other considerations will keep all but the simplest queries from being easily represented in URIs. Complex queries will require "link shortener" style URIs. (By the way, the fact that the server can create a URI that does not encode the query in the URI but which references the query probably needs to be stated explicitly. If nothing else there's a DoS consideration. Though I think this is rather obvious, so maybe not.) |
"A spec is done when nothing is left to remove". I believe you are currently over-thinking this. Let's get the basics right and ship this. FWIW: I don't see this supported by HTML, because it would require a breaking change in forms handling. We tried this ages ago with PUT. If you feel this can be done, I recommend that you follow up with the maintaines of HTML/Fetch. |
It ought to be possible for the user-agent to express a preference or requirement for one of two resulting URI behaviors:
The latter is what section 5 calls for right now, but the former might be useful too.
If a
NORMALIZE
method were also added, that might help user-agents convert between, e.g., SPARQL and an encoding of simple SPARQL queries in URI q-params. The user-agent could use a URI w/ q-params and request conversion to SPARQL, or request conversion of SPARQL to URI w/ q-params, or just SPARQL to SPARQL.But maybe a
Accept-Query-Response:
request header that could indicate the user-agent's preference or requirement for one or the other of the two above options would be useful.The text was updated successfully, but these errors were encountered: