hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Moran <mike_mo...@mac.com>
Subject Relative URIs strike again
Date Wed, 29 Jan 2003 20:10:40 GMT
I've been looking into an issue in some other, non HttpClient, code 
regarding relative URIs, and I was wondering how HttpClient handles it. 
Specifically, it is the following case:

Base: http://www.foo.com/
Relative: #

Now, I've only often seen this as a `fake' url for javascript popups, 
but nevertheless, it is not uncommon in the wild.

I've attached an example, hash.html, to illucidate. It contains three 
relative links: "" (nothing), "#" and "#anchor". Now, assuming a base 
ref of "file:///hash.html", this is what I find:

IE 5.0:
"file:///"
"file:///hash.html#"
"file:///hash.html#anchor"

Phoenix 0.5:
"file:///hash.html"
"file:///hash.html#"
"file:///hash.html#anchor"

My code:
"file:///hash.html"
"file:///hash.html"
"file:///hash.html#anchor"

I *suspect* from reading the HttpClient code, that it does the same as 
the last one, but I haven't got a working build here to test it.

I don't find the relevant rfc, rfc2396 section 5.2, totally clear on 
what to do in the case of a fragment identifier just being "#". The 
regexp given in Appendix B seems to allow for it, ie the part (#(.*))? 
will match both "#" and "#anchor". I think the tricky bit that trips 
things up is the suggested way to reassamble the URI from its parts that 
ignores the fragment entirely if it only consists of "#".

So, what way does HttpClient's URI class deal with this? Are IE and 
Phoenix/Mozilla both wrong? Answers on a postcard to ...

-- 
Mike

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message