The jar protocol should be able to read jar (or zip) files within other zip files, for example jar:jar:http://server.com/outerArchive.zip!/innerArchive.jar!/ file.txt.

This is an enhancement request; not crucial right now but it would be nice. Marking M20, as in "sometime later." Reassigning to Warren.

I'm about to mark this WONTFIX.

I doubt Warren will be working on this...so I will take it.

Open Networking bugs, qa=tever -> qa to me.

Turns out we didn't really need this, but it might be nice to have. Someone will probably want to be able to do this at some point. Reassigning to dougt - Doug, if you think this will never be necessary, go ahead and mark it wontfix.

Nice as it sounds, it breaks the URL standard, unless we call this tunneling/encapsulating, which would be a nice feature to implement for all protocol combinations, not just jar in jar, but that's in far, far future. For now as far as I can see it is evangelism. A jar is just a renamed zip, purpose of zip is providing compression, zipping it twice gains nothing, so there's no real reason to nest jars. One could as well just include the inner jar's directory tree in the outer one, without nesting, thus saving CPU time on decompressing the same stuff twice. Someone wanna submit a bug with a far-far away target, for encapsulating protocols? :) Removing keyword "verify". (what to verify?) If someone disagrees, put it back.

http://www.w3.org/Addressing/rfc1738.txt : <quote> In general, URLs are written as follows: <scheme>:<scheme-specific-part> <!--(...)--> Reserved: Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme. Usually a URL has the same interpretation when an octet is represented by a character and when it encoded. However, this is not true for reserved characters: encoding a character reserved for a particular scheme may change the semantics of a URL. Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL. On the other hand, characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose. 3.1. Common Internet Scheme Syntax While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data: //<user>:<password>@<host>:<port>/<url-path> </quote> The problem I see is ':' has three meanings already - proto, port and password separators, from which two are optional. In case where segments aren't separated with '//' or '@' it may be quite tricky to tell which is which, . Let's say we got a not-too bright user 'binks' which takes for granted the protocol is 'proto://' and assumes everything that doesn't have // in it is treated as 'http://' (like when he types 'www.aol.com' in location bar and voila, he's on his homepage!) Now he types: jar:jar:binks@gungans.org/yummy/big.jar!/frog.jar!/ Now will that be "jar:jar:<user>" or maybe jar:<user>:<password>@...? Maybe not the most fortunate example, it's 3AM and I'm just leaving for a conference so I can't think of some better one, but I leave the colon question to your consideration (remembering Murphy: If it can fail, it will.) Remembering ZIPs can be password-protected, thus jar:<pass>@.... working would be (is already?) in order, this makes the situation even more complex. If you think you've checked all suspicious configurations of embedding one protocol in another and they are safe, then go on. Simply, another axiom from Murphy's laws class: "when the problem looks simple, it's hard" and I'm just telling you how. (using : and ! as outermost brackets at the first sight looks safe for me, unless something breaks it, like DOS users who love to name directories as !dir! to render them stabnd out and be first on dir list.)

cc: andreas for URL help. Is there a spec for jar:, please put it into the URL field. RFC 1738 is not the most current URL standard (it's as far as I've gotten but I know there is something newer... My impression is that jar: points to a file in the zip file. If so, you need an escape naming convention, and my reading of RFC 1738 didn't really suggest anything like that.

No, I don't think there is a RFC about jar-urls. jars are simple urls of type scheme:something, so we should be able to nest them. jar has its own unique urlparser, no interference there.

Note with bug 309296 submitted this one works: jar:jar:http://www.pythoncriticalmass.com/downloads/TICPP-2nd-ed-Vol-one.zip!/TICPP-2nd-ed-Vol-one-html.zip!/ So, we can close this one?