search

httpwg / http-extensions

HTTP Extensions in progress
https://httpwg.org/http-extensions/
433 stars 143 forks source link

QUERY: Headers for URI options? #2899

Open nicowilliams opened 2 weeks ago

nicowilliams commented 2 weeks ago

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.

reschke commented 2 weeks ago

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?

nicowilliams commented 2 weeks ago

We can probably expect the Location: to replace the URI in the browser status bar when a QUERY is executed from HTML (which won't be possible without an update to HTML, granted), or when JS sets the document location (which also won't be possible right away). That means the Location:/Content-Location: will be part of the UI.

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.)

reschke commented 1 week ago

"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.