Christoph Fünfzig wrote: > Patrick Dähne wrote: >> Hello Marcus, >> >> >>>>> If you notice my latest wiki edit (5 minutes ago) I have read the >>>>> holy >>>>> standard and come to favour the fragment feature of url for zip- >>>>> files, >>>>> i.e. http://server/archive.zip#file.obj). (Several zips/archives >>>>> would >>>>> then just be several # in a row.) >>>>> >>>> That does not work. Consider having a relative URL "images/foo.jpg" >>>> inside file.obj. This will be transformed to the absolute URL >>>> "http:// >>>> server/images/foo.jpg", instead of the correct URL "http://server/ >>>> archive.zip#images/foo.jpg". There is a reason why Sun developed that >>>> ugly jar URL scheme ("jar:http://server/archive.jar!foo.class";), >>>> instead of using fragments... >>>> >>> I don't see why the transformation would have to ignore the # ? .. (It >>> would remove only file.obj.. not archive.zip#file.obj .. back up >>> only to >>> the first / _or_ # .) >>> >> Because the rules for transforming relative (http/file/ftp) URLs to >> absolute URLs say that relative URLs are relative to the "path" part >> of the HTTP URL and not to the "fragment" part. >> >> > The rules for resolution of relative URIs are given here > http://www.gbiv.com/protocols/uri/rfc/rfc2396.html#rfc.section.5.2 > And all depends on how the Base URI is defined: > http://www.gbiv.com/protocols/uri/rfc/rfc2396.html#rfc.section.5.1.1 > Here rule "5.1.2. Base URI from the Encapsulating Entity" > or rule "5.1.3. Base URI from the Retrieval URI" applies, I am not sure.. > > For a HTML with fragments > http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING > clearly rule 5.1.3 applies if it does not contain an explicitly set > "BASE" URL and that skips the tail "historical.html#WARNING". > But a ZIP file could be judged an encapsulating entity, but it would be > detected only by the extension .ZIP, > which is perhaps a bit fragile...
That was what I had in mind. It might be fragile as you say, but it makes sense it the same way as anchors are used with web browsers. > This could be the reason, why SUN prefered > "jar:http://server/archive.jar!foo.class"; > and the HTTP URLs are bound to webbrowsers by default. > Is it allowed to have an HTML file named "archive.zip" ;-) Hmm. Yup, HTTP gets it content type via the header, which we haven't planned upon including everywhere, and general URLs obviously have no knowledge of the http-header. And your average web-server would probably tell you that it's a zip-archive you're getting if you call it .zip, unless it is very smart. :) OTOH, we already use file-extension for the major part of selecting content type. > We could implement the rule: Relative path "images/foo.jpg" refers to > the file in "http://server/archive.zip"; if the "encapsulating entity" > "http://server/archive.zip"; > is a .ZIP file. > And a relative path "images/foo.jpg" refers to > "http://www.ics.uci.edu/pub/ietf/uri/images/foo.jpg"; (base > "http://www.ics.uci.edu/pub/ietf/uri";) in other cases! Yeah, that was what I had in mind. One point for choosing Sun's scheme over something else is that they probably have thought about it way more than we ever would like to, so their conclusion might have some valid points that we might miss. Then, Sun is a Big Corporation (tm) with Big Committes (tm) so they might not make smart choices anyway. ;) Disregarding other things, if we can live with the ugliness of the Sun syntax, it is after all an established standard that we just have to follow. I can't make up my mind. It's just choices... Cheers, /Marcus -- 'If you choose not to decide, you still have made a choice...' - Rush, 'Free Will' from 'Exit Stage... Left'. :) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
![http://www.ics.uci.edu/pub/ietf/uri/images/foo.jpg"](http://www.ics.uci.edu/pub/ietf/uri/images/foo.jpg"){kind=link}