Sponsored Link •
Bill Venners: Often service proxies won't be built from just one JAR file. When I make a URL, I'm probably referring to one JAR file, but it may refer to others. Would there be HTTPMD URLs inside those JAR files when they refer to the other JAR files?
Bob Scheifler: There are two cases. One is if your code base is a list of URLs at the top level. Every top-level URL should guarantee integrity. You can just check each one. They don't all have to be HTTPMD. You might say, "This one is HTTPMD; this one is HTTPS; and this one is some other URL scheme that I decided provides integrity." In the case of HTTPMD or even HTTPS, if it has a class path—if it is a JAR file with a class path manifest that points at other JAR files—then the expectation should be that those subsidiary URLs are also integrity protecting URLs. In JAR files, class path entries are generally relative URLs, not absolute URLs. So class path URLs inside a JAR file typically inherit the same URL protocol scheme as the JAR file's URL.
For example, if
foo.jar refers to
in its class path, it doesn't give the full URL
httpmd://host:port/bar.jar. It just says
bar.jar. The rest of the URL is inherited from the outer
one. So if
foo.jar was retrieved with an HTTPMD
bar.jar will get an automatic HTTPMD addition.
You need to worry about getting the right digest in the URL for
bar.jar. If it doesn't have the right digest then you will
either get a malformed URL exception or a bad digest, and it won't
download. Those are deployment considerations when you create a
JAR file you want to use with a HTTPMD URL. But the class path
itself can have relative HTTPMD URLs with precomputed digests.
The Jini Community, the central site for signers of the Jini Sun Community Source Licence to interact:
To get involved in the Davis project, in which Jini security is being defined, go to: