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... 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" ;-) 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! Christoph >> As I said, I'm no URL expert. I do not see the difference between >> using >> # and ! in your example. (Given that I write the transform code >> myself. >> Or are the standard rules which govern that?) >> > > The crucial point here is not using ! instead of #. The crucial point > is that Sun introduced a new URL scheme "jar:" where relative URLs > are resolved differently (compared to http/file/ftp URLs). Look > carefully at my example - the URL starts with "jar:", not with "http:". > > ------------------------------------------------------------------------- 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}