what is the best way to support zeroconf names in the location segment of a URI design?
RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) makes no mention of zeroconf and i fear the URI syntax is not designed to work beyond DNS resolution.
the ideal answer syntax will:
conform to the generic URI syntax
handle zeroconf names with multi-byte characters
Here are some options:
dnssd://local/_printer._tcp/Fancy printer/
dnssd://Fancy printer._printer._tcp.local
These strings are IRIs, not URIs, in order to address i18n issues.
a nested URI is another approach that is backward compatible. a nested URI defines the location for use with discovery protocols like zeroconf.
see 'nested uniform resource identifiers' manuel urena and david larrabeiti
however i dont find evidence this approach in is wide use.
A universal resource identifier is a generic way to locate a resource. For internationalization, you may want to check on IRI, which is almost the same, but allows for full Unicode compatibility. The reason that it doesn't mention Zeroconf is that URI is a generalized protocol. Zeroconf may use URIs are part of its protocol for discovery, but URI will never use specific implementation in its protocol (you won't find ftp:, https:, mailto:, skype: etc in there either)
Zeroconf is a protocol to automatically configure your network and discover available services. It consists of three parts, address selection (part of IPv4/6), name resolution (mDNS) and service discovery (UPnP (Microsoft), DNS-SD (Apple)). Modern operating systems support all of this out of the box.
If we take UPnP, the discovery is done based on a URI, iirc. The returned information is given in XML. XML can be any Unicode encoding. If you're a device driver manufacturer, you can place any character in there. The final phase may be presentation, which is a URL but that's optional.
A URI / URL both support internationalized characters, but only escaped and not in the domain name part.
-- Abel --
Related
Long story short, I would like to explicitly indicate a given hash algorithm (SHA256) that was used to compute the HTTP ETag header of a resource. The way I understand it, the ETag header value is opaque by design, but in practice it is common to compute it using a hashing function.
I understand the idea of keeping the ETag value opaque, which I guess it there to prevent unintended optimizations by caching proxies that would try to interpret its value and do something other than compare the current ETag with the cached ETag. However, I was wondering if someone wrote an RFC defining usage of an additional HTTP header that would explicitly indicate a hashing algorithm used to compute the corresponding ETag value, therefore making it non-opaque, while remaining compatible with caching proxies that rely only on the opaque ETag value.
In my case, I am not using a caching proxy: I have a native application that should fetch multiple resources from own HTTP microservice, which means I control both the HTTP client and server implementations. Some of these resources are meant to be stored on disk, and as an optimization I would like to simply load the current file, compute it's SHA256 sum, and use it as the ETag of the last cached resource when fetching the same resource again from my microservice.
In other words: I make GET requests on a specific resource that does not change often, but I still need to check at regular intervals. Instead of transmitting the resource over the network every time, I would like to compute the SHA256 sum of the file and use it as ETag, allowing me to avoid saving the opaque ETag alongside the file. Since I control the microservice serving the resource, I could easily use SHA256 sums as the ETag, and add a custom header to indicate that SHA256 was used to compute the ETAg. This ETag can remain opaque to clients not checking for the custom header, but those that can will treat it as a SHA256 sum.
Are there known implementations of something like this? I'm fine with using an obscure RFC that is not widely recognized, or some REST API documentation, but I'd rather look for existing designs I could implement before making my own. If I missed the widely recognized standard, it would be more than I wish for :)
The semantics of a REST service is not given by any standard or RFC. Only you can specify the semantics of your REST service. This specification adds constrains or interpretations on top of the basic constraints of HTTP (etc.). If you want to specify that the ETag returned by your service is the SHA256 checksum of the representation, you can. Nothing more is needed. You don't need a special extra header or need to conform to some externally produced standard.
According to RFC 6648 which has deprecated the 'X-' convention, there is no reason to prefix custom headers like API key with 'X-' for designing web API now.
In spite of RFC standard, I wonder that it is really safe to conform the new convention, without 'X-'. Someone says that some browsers or even some ISPs which follow the old convention may block such headers which follow the new convention by reason of non-standard but I couldn't confirm that yet.
The solution would be simple, supporting both conventions or old convention only. Though, regardless of the solution, I'd like to know if it is safe or not to conform the new convention or is a question with no answer.
I am confused here! I read a blog and it said in RESTful architecture,we can use more than one URI to represent a resource.
Is this right,since URI is use as identifier,it should be unique. Did I misunderstand something?
Sorry I am not going to post the link of that post because it is written in Chinese:)
Yes that is true. REST follows existing standards (aka. uniform interface constraint), now we are talking about the URI standard.
I think the simplest example about this is localhost. So imagine you have a REST service on http://localhost/api on your computer. Now by default you can reach the same service using http://127.0.0.1/api. So even the api root does not have an 1:1 relationship with the URIs in this case. In terms of the URI standard uniqueness means an 1:n relation between the resource and the URIs. This is different to the uniqueness term you are used to by relational databases. So in different words, a single resource can be identified by multiple URIs, but a single URI can identify only a single resource.
I've often seen "bis" appended to versions of protocols (eg v.34bis or httpbis).
What does "bis" mean or stand for?
A telecom engineer I know thinks it might be French in origin.
As others have already said, "bis" comes from "twice" or "repeat". It's used to indicate a second variant of something (although usually with only minor variations that don't warrant a new name).
In the context of HTTP, HTTPbis is the name of the working group in charge of refining HTTP. According to its charter:
HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial
issues. Additionally, after years of implementation and extension,
several ambiguities have become evident, impairing interoperability
and the ability to easily implement and use HTTP.
The working group will refine RFC2616 to:
Incorporate errata and updates (e.g., references, IANA registries, ABNF)
Fix editorial problems which have led to misunderstandings of the specification
Clarify conformance requirements
Remove known ambiguities where they affect interoperability
Clarify existing methods of extensibility
Remove or deprecate those features that are not widely implemented and also unduly affect interoperability
Where necessary, add implementation advice
Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications
It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition
of the Basic and Digest schemes.
Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.
In doing so, it should consider:
Implementer experience
Demonstrated use of HTTP
Impact on existing implementations and deployments
The Working Group must not introduce a new version of HTTP and should
not add new functionality to HTTP. The WG is not tasked with producing
new methods, headers, or extension mechanisms, but may introduce new
protocol elements if necessary as part of revising existing
functionality which has proven to be problematic.
The last paragraph (emphasis mine) explains why they've used "bis" in this context, since they explicitly don't want a new version.
bis
The word (also used as a prefix or suffix) bis , applied to some modem protocol standards, is Old Latin for "repeat" (akin to Old High German "twice"). When a protocol ends with "bis," it means that it's the second version of that protocol.
Similarly, ter is from Old Latin meaning "three times." The suffix terbo in the V.xx modem protocol is an invented word based on the Old Latin ter and the word turbo (Latin for "whirling top" or "whirlwind") meaning "speed." V.32terbo is the third version developed of the V.32 modem protocol..
(from http://whatis.techtarget.com/definition/0,,sid9_gci211669,00.html)
am using Jena, Java to generate RDF statements. I want to know if there are rules I need to follow to generate resolvable URIs.
I think you're talking about what is now referred to as linked data, and yes, there are patterns you should follow. At its simplest, you should (i) use http: URI's, (ii) ensure that those URI's refer to locations in a web space you control, and (iii) ensure that an HTTP GET request to those URI's, with an appropriate mime type, will result in machine-readable representations of the resources they denote.