Here's a Google Desktop URL: "http://127.0.0.1:4664/&s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q=".
Internet Explorer properly treats everything after the last '/' as a query string (even though starting query string with '&' instead of ' ' is odd). To prove this is the case just look at the page sorce and see google desktop logo <img> has relative src=hp_logo.gif, which corresponds to http://127.0.0.1:4664/hp_logo.gif URL (check image properies in the browser). Now load the same http://127.0.0.1:4664/&s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q= URL into the .NET Framework 1.1 URI class. Observe Query property = "" while Segments collection having "&s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q=" in it. Looks like a sure bug. Does this have a fix
Regards,
Vlad Hrybok.
Discrepancy between how Uri class parses URL and the way Internet Explroer does it?
jarcid
Maybe I got this all wrong, but isn't it the webserver that parses the url, and the server can choose to handle the part after the server address however it sees fit So it is not really a querystring, just some string that google desktop handles somehow internally. IE only parses out the server to send the entire thing to.
october
I would guess that in IE the &s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q= portion of the URI is treated as a filename, not as the query. This would mean that when IE went to load logo3.gif, it would append logo3.gif to the relative path to the directory (which is just '/') and is then able to get the correct resource.
Christopher Varney
Of course it does! Having <img src="file.jpg"> is totally legit and all browsers without exception treat it as a relative path. Here's the actual tag from Google Desktop page:
<IMG border=0 height=110 alt="Google Desktop" src="hp_logo.gif" width=276>. There's no "/" in front of "hp_logo.gif", so it's not path from the root.
BTW, I'm not sure at this point, but I think that IIS (at least IIS5) too doesn't treat "&a=b" as a query string in the URL like http://host/folder/resource.aspx&a=b.
Vlad.
shihuey
You're right, I had looked at a search result page and there they had a / in front of the logo img link. Anyways, could it be that the "&s=..." part is treated as a file
Luis Martinez
I don't think so. It's a client side business too. Consider this: IE requested "http://127.0.0.1:4664/&s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q=" and received a piece of html looking like this <img src=hp_logo.gif>. To display the image IE needs to make an aboslute URL "http://127.0.0.1:4664/hp_logo.gif" out of relative URL "hp_logo.gif" to request the image. For that IE needs to know exactly which part of the URL in its address bar is path, and which is query string. IE didn't request the image from the "http://127.0.0.1:4664/&s=8lD6KsMwZ1Zd3ZWWqfZb327gN6g&q=/hp_logo.gif". Instead IE determined that "&s=8lD..." is a query string and correctly requested the image from "http://127.0.0.1:4664/hp_logo.gif". AFAIK, server does not tell the client which parts of the URL are path, and which is the query string. So IE must have figured it out on its own. The same way as Uri class parses out the URL without contacting server. The difference is that IE does it right, and Uri class does it incorreclty.
Vlad.
Me-myself-I
IE does not just append the relative url to the current url when requesting images. If you look at the page source of a google desktop search page you'll notice that the url for the logo is <img src="/logo3.gif"> and not <img src="logo3.gif">. So unless I've missed something about the whole url thing, the image url is relative the root "http://127.0.0.1:4664".
bigballball