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

[John Arwe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120906/f223c13e/attachment.html>