according to the answer to this question: In OpenRasta, how do I configure a URI where I get "the remainder of the path" as a single string?
Openrasta should support wildcards in it's uri mapping, is this already supported in version 2.1?
thanks,
Rob
Related
In an OSGi environment ClassLoader.getResource() typically returns a bundle-entry/bundle-resource URL (using a corresponding protocol).
The OSGi specification chapter 3.9.6 - "Resource Loading" specifies only a few aspects how those URLs have to be constructed (for example the path) and leafs everything else to the implementation.
Is it possible, and if yes how, to obtain the Bundle to which a bundle-entry URL is pointing, using only implementation-independent OSGi API?
For example for a jar-URL one can open a connection, cast it to JarURLConnection and use JarURLConnection.getJarFile() to obtain the JarFile.
Is it possible, and if yes how, to obtain the Bundle to which a bundle-entry URL is pointing, using only implementation-independent OSGi API?
Not in a specified way. The OSGi specification deliberately leaves URL details opaque to allow implementation freedom to the framework.
For specific framework implementations, you may be able to discern the bundle id in the URL. But this is subject to change at the desires of the framework implementation.
For example I meet this url type: http://username:token#example.com/protected/files .
I searched on the web for this but I don't find what I expected.
Wikipedia explains the syntax of a URI quite well:
scheme:[//[user[:password]#]host[:port]][/path][?query][#fragment]
Your username:token#example.com/protected/files may look like and URL, but if fact it is not, because it does not include the protocol to access the data. It is an uri.
Browsers (I suppose you refer to web browsers) do work with URL's, which is a subtype of URI that includes the protocol. Please notice web browsers dont work with all existing protocols, only with some of them (http, https, ftp, file...) username is not a protocol.
Given a known OData endpoint, what's the best way to determine the version of the OData service? The client in this scenario can support any version (1-4) but I need to know how to format the request.
For example, the OData-Version returns "4.0" for a V4 service, but a V3 service wouldn't even have that header.
In addition, querying the service root URL could be quite expensive for a service with a large number of entities. For example, a basic Dynamics 2016 Online service with no custom objects returns 2.7KB of data, when all I really want is the version header.
So what is the lightest-weight solution for getting a reliable version number? It's ok if the solution is "check this or, if missing, then check that". What's the "this" and "that"?
I found one question (How to find OData version from metadata) which seemed to get me partly there, but there are some issues with the answer.
First, it's focused on finding min/max version numbers where I would really prefer the max.
Second, it requires querying metadata, but that's a potentially massive load. /$metadata on Dynamics CRM 2016 Online results in a 3.7MB response (that takes 30 seconds to download on my current connection). I thought about requesting a dummy entity, like /dummy__entity and then examining the headers, but that seems a bit iffy to me because it would unnecessarily trigger error logging on the server and I'm not sure that an error response is always likely to have the headers I'm looking for.
OData 1.0/2.0/3.0
According to MS-ODATA 1.7 Versioning and Capability Negotiation:
The OData protocol that is defined in this document enables limited capability negotiation using the DataServiceVersion (section 2.2.5.3) and MaxDataServiceVersion (section 2.2.5.7) version request headers and the DataServiceVersion (section 2.2.5.3) response header.
When it says "limited", it means limited:
In a response from the server to the client, the DataServiceVersion (section 2.2.5.3) header is specified. The value states the version of the protocol that the server used in the request to generate the response and that is used by the client to determine if it can correctly interpret the response (that is, the value is not larger than the value of the MaxDataServiceVersion (section 2.2.5.7) header sent in the associated request). The value of the header is the lowest version of the protocol the server can use to fulfill the request.
So, basically, a conformant service capable of handling OData versions 1.0 to 3.0 would return "1.0" for features defined by OData 1.0, "2.0" for features defined by OData 2.0 and not present in OData 1.0, etc.
OData 4.0
According to OData Version 4.0 Part 1: Protocol, Section 8.1.5 Header OData-Version
OData services MUST include the OData-Version header on a response to specify the version of the protocol used to generate the response. The client MUST interpret the response according to the rules defined in the specified version of the protocol.
According to What's New in OData Version 4.0, Section 2.1.1 Improved: Protocol Versioning
Services now respond with the maximum protocol version supported by the server and indicated acceptable by the client.
Also "downgrade" to versions prior to 4.0 is not covered, and service publishers are advised to use new service root URLs for 4.0 services.
So for future versions of OData, from 4.0 onward, it seems that I can reliably get the maximum version I was seeking.
Conclusion
There is no apparent way to get the maximum version of OData supported by a pre-4.0 service. The DataServiceVersion response header will contain the lowest possible version number based on the URL features present, the version of OData that the service supports and the client-requested version.
However, beginning with OData 4.0, the OData-Version response header will always contain the maximum version based on what the service supports and what the client requested.
Unfortunately, in every instance I've tried so far, passing a "DataServiceVersion" header to an OData 4.0 service results in a 500 Internal Server Error response (with no OData-Version header). So it would seem that sending both OData-Version and DataServiceVersion headers isn't guaranteed to work.
Best bet seems to be sending OData-Version and then looking for a DataServiceVersion response header (which will likely be "1.0" even for a service that supports 3.0). If that header is present in the response, then send a second request with a DataServiceVersion header of "3.0". If you get a 4xx response, then try "2.0" etc.
Is it correct to statically set up Microdata’s itemtype attribute with HTTP value (http://schema.org/WebPage) on HTTPS pages or do I need to use HTTPS value (https://schema.org/WebPage) on all pages?
Since both HTTP and HTTPS versions of the site are available, can I set it up to //schema.org/WebPage or not?
tl;dr: Use http URIs.
In this answer on Webmasters SE I explained why you should favor http over https Schema.org URIs: The http URIs seem to be canonical, as the actual definition of the Schema.org vocabulary only defines http, not https. In addition: all examples (even on HTTPS) use the HTTP variant, the authors mentioned that they prefer to see the use of the HTTP variant, and RDFa’s Initial Context defines the HTTP variant only (so most of the RDF world will use HTTP).
In this answer on Webmasters SE I explained why you should not use protocol-relative URIs for vocabularies: Vocabulary URIs typically don’t get dereferenced, and there will never get something embedded from a vocabulary, so there is absolutely no need to use HTTPS for these just because you use HTTPS (it’s similar to simply linking to an external page, which might not even be accessible via HTTPS). On top of that, your Schema.org markup would no longer work if the document is accessed via a different protocol than HTTP/HTTPS, and it’s likely that some parsers won’t be able to recognize that you are using the Schema.org vocabulary because they might look for full URIs without applying URI resolution for the itemtype attribute.
There's been an update to that answer on Webmasters SE (dated November 2015), with a link to the schema.org FAQ about https:
Q: Should we write https://schema.org or http://schema.org in our markup?
The short of it is that schema.org will be moving to https, and you can use https URLs now, but there's no rush to switch.
Regarding protocol-relative URLs… please don't use them as they're a hack. Favor use of absolute or root-relative URLs whenever hyperlinking documents on the Web.
Is it correct to statically set up Microdata’s itemtype attribute with HTTP value [...]?
Either HTTP or HTTPS is fine in your itemtype according to the Schema.org FAQ. Your examples containing HTTP and HTTPS schemes are both correct for pages served with and without TLS.
If you've got a mix of absolute URLs pointing to different schemes it's more likely a person will notice it and wonder why things aren't consistent. So when you update refactor your existing itemtypes.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the difference between a URI and a URL?
Is there any difference? I'm talking about URI for identifying, but URL for locating. Aren't both the same thing?
They can look the same, but they're not the same thing. A URL identifies something that can be transferred over some protocol (often http). A URI, can be used to identify a namespace (for example) but there might not be any content at the address.
Where is the difference between locating a ressource and identifying a ressource?
Knowing who I am doesn't tell you anything about where I am.
A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource.
A URL is a specialization of URI that defines the network location of a specific resource.
Generally, if the URL describes both the location and name of a resource, the term to use is URI.
This article might help:
URI vs. URL
Excerpt:
"...a URL is a type of URI that
identifies a resource via a
representation of its primary access
mechanism (e.g., its network
"location"), rather than by some other
attributes it may have. Thus as we
noted, "http:" is a URI scheme. An
http URI is a URL. The phrase "URL
scheme" is now used infrequently,
usually to refer to some subclass of
URI schemes..."
An identifier is a unique name for something, so we can be sure that we talk about the same thing. For example the Atom namespace is 'http://www.w3.org/2005/Atom'. This is a URI. This doesnt mean that you can put this URI in a browser and have a document there (well, in case of Atom, yes, you have a document, but it's a simple presentation of Atom for convenience, it's not the Atom namespace itself).
A URL is the location of a document. This is what you can put in your browser. It is confusing that both use the same format (http://...) but that is mostly annecdotic ...
A URL is a URI which is not a URN. (see)