3 ms·

CGIProxy has full javascript support. It also handles cookies and can dynamically determine whether or not it should proxify images and CSS assets. CGIProxy a

by eserorg 17y ago

CGIProxy has full javascript support. It also handles cookies and can dynamically determine whether or not it should proxify images and CSS assets. CGIProxy also handles flash. In fact, CGIProxy can fully proxify an SSL-encrypted GMail session out-of-the-box. CGIProxy is _very_ mature technology. Take a look at the source code -- it handles 100's of special-cases. Some of the special-cases that CGIProxy handles are truly bizarre. Reading through the CGIProxy source code is actually pretty fascinating. This brings up an interesting point. If you're interviewing a software engineering candidate, ask them what their favorite language is. Next, ask them to write a simple HTTP server in that language. Finally, ask them to write a reverse HTTP proxy that works with the server they just wrote. This is a surprisingly effective way of separating the wheat from the chaff. Most people with CS degrees are completely incapable of doing this.

immad 17y ago
It rewrites the flash and javascript so that they call your reverse proxy instead of the original domain?
- eserorg 17y ago
  Yes.
  - catch23 17y ago
    Well it doesn't seem to work all the way. I'm not sure what you meant when you said it has "_full_ javascript support" and is "very mature technology". I tried it out with amazon.com and none of the menus seem to be working... Feel free to give it a run through: http://bit.ly/5WVsw http://bit.ly/5WVsw (this is cgiproxy 2.1beta19 running on mod_perl on a fresh lenny instance -- no ssl configured here)
catch23 17y ago
I downloaded to take a look at the source, they do things that are similar to us actually, and they do have lots of great special case handling that we might use for reference later. One crazy thing that we do that isn't done here is the storage of cookies, we actually temporarily store cookies on the server side so that we can do fancy things with it -- sending around the shopping cart, transfer of shopping state etc. However, if you've tried using it, you'll notice that it isn't perfect either... they show slashdot.org as an example, but lots of things are broken on it. Most of the javascript stuff doesn't work. Slashdot was a javascript light site a year ago, but now they use tons of fancy javascript like most sites. Their cookie support also seems to be broken -- not sure why. Although I will admit that James did quite a bit of amazing work in just 12k lines of perl code. The perl code is pretty decent too. It's easy to get a proxy that works on 95% of the code, all the hard stuff is in that last 5% -- that's what we spent most of the time on :-)
jeffDef 17y ago
I evaluated cgiproxy at the beginning of this project, along with a variety of apache mods and other libraries. cgiproxy didn't work for most of the merchant sites that I checked. Was an oversight to ignore them thereafter though. Like you said, they've put a lot of time into special cases, and we can learn things from them. Their primary goal is anonymous browsing. Ours is collaborative shopping, or more specifically, adding new functionality to existing sites. Our proxy lets us do amazing things with client state, image scraping, and more. A different tool for a different problem.

by eserorg 17y ago

immad 17y ago

It rewrites the flash and javascript so that they call your reverse proxy instead of the original domain?

eserorg 17y ago
Yes.
- catch23 17y ago
  Well it doesn't seem to work all the way. I'm not sure what you meant when you said it has "_full_ javascript support" and is "very mature technology". I tried it out with amazon.com and none of the menus seem to be working... Feel free to give it a run through: http://bit.ly/5WVsw http://bit.ly/5WVsw (this is cgiproxy 2.1beta19 running on mod_perl on a fresh lenny instance -- no ssl configured here)

catch23 17y ago

I downloaded to take a look at the source, they do things that are similar to us actually, and they do have lots of great special case handling that we might use for reference later. One crazy thing that we do that isn't done here is the storage of cookies, we actually temporarily store cookies on the server side so that we can do fancy things with it -- sending around the shopping cart, transfer of shopping state etc. However, if you've tried using it, you'll notice that it isn't perfect either... they show slashdot.org as an example, but lots of things are broken on it. Most of the javascript stuff doesn't work. Slashdot was a javascript light site a year ago, but now they use tons of fancy javascript like most sites. Their cookie support also seems to be broken -- not sure why. Although I will admit that James did quite a bit of amazing work in just 12k lines of perl code. The perl code is pretty decent too. It's easy to get a proxy that works on 95% of the code, all the hard stuff is in that last 5% -- that's what we spent most of the time on :-)

jeffDef 17y ago

I evaluated cgiproxy at the beginning of this project, along with a variety of apache mods and other libraries. cgiproxy didn't work for most of the merchant sites that I checked. Was an oversight to ignore them thereafter though. Like you said, they've put a lot of time into special cases, and we can learn things from them. Their primary goal is anonymous browsing. Ours is collaborative shopping, or more specifically, adding new functionality to existing sites. Our proxy lets us do amazing things with client state, image scraping, and more. A different tool for a different problem.