[oslc-core] handling of long URIs, e.g. those in query strings

Thu Sep 6 09:34:19 EDT 2012

Well,

With my implementers hat on, Design Management (and OSLC AM and RM
provider), does allow the POSTing (x-www-form-urlencoded) of queries to the
OSLC defined Query Base.  This was explicitly allowed to permit the
potentially very long queries that are getting created when RRC queries DM
for links from model elements to requirements.

Presently DM does not share the same query base and factory URL, so this
has not been an issue so far.

We do not explicitly say this must be supported by the OSLC AM (or RM)
spec.

While I consider it a minor issue (compared with other core issues), I do
think it would be nice if we addressed this formally.  I do foresee long
query expression being made quite often.

Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group

From:	John Arwe/Poughkeepsie/IBM at IBMUS
To:	oslc-core at open-services.net,
Date:	09/06/2012 07:43 AM
Subject:	[oslc-core] handling of long URIs, e.g. those in query strings
Sent by:	oslc-core-bounces at open-services.net

I got a question from internal implementers about how OSLC handles long
URLs, e.g. those that result in an HTTP 414 URL Too Long status code.

I know about the ability to bind/use prefixes in Query Syntax, and those
would be a first defense.

The common Web pattern is to turn "GET overly long URI with lots of query
parameters" into "POST long URI" + a form-encoded payload with the query
parameters.  It occurred to me that I don't recall seeing this called out
(either for or against) in Core, hence I wondered if the omission was
intentional/not. A bit of searching, spec prospecting, and discussions with
previous Core authors here leads to the following:

The Core spec says: A Query Capability describes a query capability,
capable of querying resources via HTTP GET or POST. [1]

[1] open-services.net/bin/view/Main/OslcCoreSpecification

True, but - nowhere I can find does it say -how- one uses POST to do so...
e.g. that form-encoding is what people should do, and there's an existing
media type for that, etc.
So someone who already knows the right answer (by which I mean the one we
intend) might find sufficient prompting in that text; any newbie will have
no idea of its significance.

That extra detail succumbed to the editor's knife. I agree that we should
add it back.

It does appear that when the Core editors removed query form encoding from
the Core spec (earlier in this thread), they forgot to remove it from the
Core vocabulary documents (Query Capability).

---
The behavior should be what a browser does on an HTML form when you set
METHOD=POST. The media type is application/x-www-form-urlencoded

The resolution we came up with at the time is that if the content type is
application/x-www-form-urlencoded, then the request is ALWAYS interpreted
as a query via overloaded POST, and NEVER as a request to create a
resource.

We also know that it is common implementation practice today to use a
single URI for both creation factory and query capability.  Indeed, W3C's
Linked Data Basic Profile 1.0 work suggests making that the preferred
implementation pattern.  The approach above assumes that an OSLC POST [for
creation] would never have content type of
application/x-www-form-urlencoded - effectively ruling out the default
browser based form submissions as input to a creation factory.  In order to
do that, one needs an intermediary adapter layer, e.g. code [js] in
"onSubmit" [to convert the form data to a OSLC supported mime type/format]
or a form submission URL.  This is not a problem today because no OSLC spec
defines resource representations that use the content type
application/x-www-form-urlencoded.  We would have to acknowledge that, and
it would likely lead to more consistent implementations if we gave some
guidance on how to handle that generally.

E.g. In practice, you'd POST application/x-www-form-urlencoded create
requests to a form handler, not the creation factory. It would validate the
data and create an RDF representation, then POST that to the creation
factory.

Combining the "form-encoded POST request entity bodies are always
interpreted as queries" with the example guidance above for dealing with
form-encoded "create" requests
seems very much in keeping with collapsing a container's OSLC's Query
Capability and Creation Capability into a single W3C Basic Profile
Container (by using the same URL for the QC and CC).

Considering the scenarios separately (they are related because of the
common implementation pattern and W3C BP pattern to support both QC and CF
on the same URL).

1. POST a long query. You'd send this to a query capability. If the query
capability was also a creation factory, then the creation factory would
NOT try to create a resource since application/x-www-form-urlencoded is
not a defined resource representation type.

2. POST a creation request of type application/x-www-form-urlencoded.
You'd POST this to a URL that would NOT interpret this as a query. If you
POSTed it to a creation factory that was not also a query capability then
it would be implementation-dependent how to interpret the content since
AFAIK, no OSLC spec defines resources using the type
application/x-www-form-urlencoded . In practice, you'd only do this from a
UI page. Aside from delegated UI, OSLC does not specify UI. Therefore, any
URL that accepts creation requests for resources defined using
application/x-www-form-urlencoded is implementation-specific.

In summary, if the URL supports both query and creation, then
application/x-www-form-urlencoded MUST be interpreted as a query. If the
URL
only implements creation then it is not specified how to interpret
application/x-www-form-urlencoded, i.e. the service interprets it in an
implementation-specific way. A creation factory MAY
map it to RDF and use the specified interpretation as input to a create
request.

Which OSLC spec(s) define the meaning of
application/x-www-form-urlencoded  for resource creation?
I see none for creation; Google results suggest all existing references on
open-services.net are for query (AM query V1 appears to be the only domain
spec).

One implication of this would be - we would miss out on the caching [Etag
stuff], since ETags do not apply to POST and POSTs generally are assumed to
be non-cacheable by HTTP.  Though some have questioned how
static/cache-able query responses are anyway.

It has been suggested that we create a Core Issue on this, so the tortured
narrative above should suffice as a discussion starter.  Before I start
drafting spec changes to throw produce at, is there any objection to the
basic approach outlined above or does anyone think a different approach is
better, e.g. just consistentizing Core by remove the straggling reference
to POST for queries from Core and the reference to form encoding from the
vocabulary document?

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120906/1f231d22/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120906/1f231d22/attachment.gif>