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 [email protected] Rational Software, IBM Software Group From: John Arwe/Poughkeepsie/IBM@IBMUS To: [email protected], Date: 09/06/2012 07:43 AM Subject: [oslc-core] handling of long URIs, e.g. those in query strings Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
