The Un-Official Proxomitron Forum

Full Version: URL commands aren't working (for me) in IE9
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I recently bit the bullet and upgraded to Win7 with IE9. I figured, what the hey, it came on the new Dell Inspiron, so why not at least try it, before summarily dumping it.....

All works as intended, except that like the title says, Proxo's URL commands don't work. Strictly speaking, I can get local.ptron/{...} to work, but as Scott says, that's not really a URL command.

I've tried every one of them shown in the Help file, and they all come back with "Cannot display the webpage". Of course, if I bypass Proxo from the main interface, then I couldn't use these things anyway, so that's not an option for troubleshooting, sad to say. (Actually, I get the same message, but then I'd expect to.)

I also watched the Log window, and unexpectedly, IE isn't even attempting to send the request out to the web. This isn't usual - when I ask for bypass or dbug, the page is always reloaded on my old XP/IE6 machine, at least according to the Log window. However, interestingly enough, if I ask for "Debug Info" from the Log window's menu, every page then loaded into the browser comes in like it should - the page code is displayed, along with Proxo's additions. Puzzling, no?

All of my (not exactly stock) Proxomitron filters work just like they did under XP/IE6, so I'm not suspecting them, nor the overall operation of IE and Proxo. I was (emphasis on 'was') pretty sure that it was a security level issue, so I completely demolished all security settings, effectively leaving me open to whatever the web could throw at me. Aside from a few popups, nothing.... bupkis... zilch.... no effect. (Restored all security settings forthwith.)

SmartScreen? No effect, either on or off. ActiveX control? Ditto. Tracking Protection? Don't see how it could cause this, but I disabled it too - no effect, either way.

In short, I'm at my rope's end. I've searched this place, as well as googled the rest of the web, and haven't seen quite this problem come up for discussion. Anyone got any clues for me, please? ???

Thanks!



Oddysey


p.s. Could I live without dbug and bypass? Sure. But I can't live without http://https.. - that's critical for my needs. I don't want to just bypass Proxo entirely, it's a matter of the desired sites being not only secure, but also greatly offensive to my eyeballs. You can guess the rest from there, right? Wink
my reply may be of limited assistance, but i'll offer what tidbit i know...

my parents run Win7 with IE9...
i was just there for a week over Christmas and it never dawned on me to run Proxo on their IE9 "directly"...
i did however run my IE shell (GreenBrowser) and Proxo from my USB stick and everything seemed to work just perfectly, including half-SSL http://https.. (can NOT live without it!)...

i must also point out, however, that in Win XP, GreenBrowser, while "portable", does require a local registry entry in order to run "IE8 Emulation Mode"...
i didn't run any user-agent tests while at the parents, so i can't say for 100% that i was "shelling" IE9, per se...

IE9 was installed, and fully updated, but i could very well have been "shelling" 'compatibility mode' or something like that...


i'm not sure how much help that is Sad



in other news, my Acer Aspire netbook picked up a little over a year ago came with Win 7 with IE9...

i can not claim this to be true for a DESKTOP computer, but i ran extensive dual-boot side-by-side tests comparing Win XP and Win 7 on the NETBOOK... turned off all of the "aero CRAP" on the Win 7 and every other "power saving" tweak i could muster up... keeping in mind that Win 7's power-up and power-down is, by default, NOT a power-up/power-down (and therefore MISLEADING to the eye as to how "fast" it powers up/down)... ie, it is equivalent to XP's HIBERNATE, not XP's "on/off"...

Win XP would boot up and shut down FASTER...
From the time the power button was hit to the time the last process loaded...

for the NETBOOK, i'd average 5.5 to 5.75 hours of battery life on Win 7 but would get 7.0 to 7.25 hours of battery life on Win XP...
that coupled with SEVERAL other "nuances" FORCED me to "downgrade" from Win 7 and install only Win XP onto the netbook...

there also are XP tweaks to get 1024x768 resolution and 7 was stuck with 1024x600...

but like i say, i cannot claim i would have "downgraded" on a DESKTOP (most likely would have, lol)...
PR;

Thanks. I figured that most IE wannabes, like GreenBrowser, are shelling the rendering engine, but I don't rightly know if they are also using the underlaying method of accessing the network transport layers, or if they have implemented their own protocol handlers. Hence, your test is, as you guessed, inconclusive. But like I said, thanks for at least trying. Wink

This Dell came with the usual Bloatware foisted on us by manufacturers, and that included W7/SP1 and IE9, complete and all ready to go. It goes without saying that I immediately busted out CrapWareRemover (or some such...), and the system was actually pretty lean and mean. However, I also just happen to have a copy of W7Ultimate on hand, and you can guess what's coming, can't ya? Wink

Right-oh! Very fast, much quicker in all respects than HomePremium. Let the system access Windows Update once, for IE9 (never gave IE8 a chance), and whoala, I'm back -bigger, faster and meaner than ever!

Of course, like you, I'm an XP diehard, but sadly for me, there's a major conspiracy out there, whereby Microsoft is either paying, or bullying, driver writers to not come up with XP drivers for new hardware. That means that nearly every less-than-4-year-old feature on my new laptop is rendered null and void, vis-a-vis XP. Not a good way to spend money, IM(ns)HO. Sad Hence, I've 'sacrificed' speed for usability. Indeed, with four cores and 8 gigs o' RAM, I don't really feel the sting so much....Whistling

Enough bragging. I've twisted and torqued my system so much already that this is just about the only remaining issue to deal with. From the lack of direct results via Google, I'm beginning to wonder if it ain't me and my system, and not truly a 'bad software' issue after all. Guess that means more tinkering for me. Pray

Anyone else have anything for consideration?



Oddysey
"dotdot" URL Commands will not work with IE7,8, or 9.

You can pass the URL commands to Proxomitron with a query string. sidki set has been passing many commands via a query string for awhile.
You could also change the dots to dashes or ??.

Either way:
You'll need to redirect the request to the correct URL command syntax.
You'll probably also want to strip the commands from the Referer.

Some of the filters could look like:

Code:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "Referer: Hide URL Commands (out)"
Match = "\1\?proxo=((src|dbug|bypass|bout|bin|bweb)..)+{1,*}(^?)"
Replace = "\1"

In = FALSE
Out = TRUE
Key = "URL: Redirects for Query String URL Commands (out)"
Match = "(http(s|)://)\0\1\?proxo=(((src|dbug|bypass|bout|bin|bweb)..)+{1,*})\2(^?)&$RDIR(\0\x\2\1)"

Some of above is from old post a prox-list. I think there was more at castlecops.

I think CURI, http://blogs.msdn.com/b/ie/archive/2005/08/15/452006.aspx , is the cause.

HTH
(Jan. 17, 2012 01:50 AM)JJoe Wrote: [ -> ]"dotdot" URL Commands will not work with IE7,8, or 9.

sidki set has been passing many commands via a query string for awhile.
You could also change the dots to dashes or ??.

ah yes, right you are...
i had actually totally forgotten that Proxo has its own "dotdot" commands...
First, a hearty "Thanks!" to JJoe, he led me to the correct solution.

Second, an admission of my own embarrassment at not recalling all this dicussion at the time of IE7's introduction.

Third, the problem is solved. I had been so smitten with my long-ago written Favorites links (those explicitly using URL commands, with the two dots) that I was completely forgetting that there is an alternative. JJoe's mention of "change the dot characters to dashes or something else" prompted me to, once again, go to the source.

As usual, all praise to Scott for looking ahead. Wink One is not limited to two dots, one may also use.... two slashes!!! Oh boy, and here I was, all ready to start looking for a new browser, one that didn't think that The Proxomitron was a bad guy, trying to shiv my browser into committing mayhem on my system.

Not that I'm so dead-set on IE, it's just that after decades (not just years, but several decades) of being the guinea pig, I've had it with fooling around "what might be" - I'm willing to use what's provided, and live with that. If/when something doesn't work right, or doesn't work at all, I've got Proxo to get me over that hurdle - what more could a guy want, eh? Wink

So, a few moments with MED, and I'm back to the races. For the occasional trip out the door without galoshes, I'll probably get my feet wet, until I remember to train my fingers to use dbug// or bypass//, instead of the 13-year-old habit of two dots. I think I can stand that kind of training regimen, thank you very much. Smile!

Cheers to all, for showing me the light! Thumbs Up And I hereby nominate Scott R. Lemmon for sainthood!!



Oddysey
(Jan. 17, 2012 05:41 PM)Oddysey Wrote: [ -> ]use dbug// or bypass//, instead of the 13-year-old habit of two dots.

Be aware, cookies may not be sent and some may be sent to sites that they should not be.

Have fun
perhaps shifting the third digit to the second instead -

dbug,,
bypass,,


edit: that is, assuming it's the // causing the cookie issue...
(Jan. 18, 2012 11:30 AM)ProxRocks Wrote: [ -> ]edit: that is, assuming it's the // causing the cookie issue...

Apparently, Oddysey has rediscovered another way to call the Proxomitron's native URL commands.

Assuming that you have URL commands enabled and the prefix is "px.",
http://px.dbug//prxbx.com/ may get you the Proxomitron's debug page for TUOPF's homepage.

The problem with // is that the browser thinks it is dealing with "px.dbug/". Cookies, relative links, and such may depend on the browser knowing the correct host.

I think.

HTH
JJoe,

The way I see, if a request to set (or get) a cookie is initiated with a relative address, then you're at least 99% correct, it's likely to fail. But if the address is absolute, then I'd tend to think there would be no issues.

At this point, I don't seem to be having any problems, at least not with sites that I visit every day. If one comes along that gives me an error, and specifically leads to cookies as the root cause, then I'll investigate more closely. Until then, I'm just gonna sit back and enjoy the ride. Whistling

Thanks again! Cheers



Oddysey
Reference URL's