Support for proxies (configuration file?)

[alextreppass]

alextreppass@gmail.com commented:

What steps will reproduce the problem?

1. Call rasterize.js with the raphael polar clock example on a computer behind a proxy

What is the expected output? What do you see instead?

• Operation will timeout and an empty .png will be drawn
• No error messages on console

What version of the product are you using? On what operating system?

• 1.0.0

Please provide any additional information below.

• A config.ini or something with a [network] section would be great, something along the lines of how subversion does things.

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #19.
🌟   7 people had starred this issue at the time of migration.

[ariya]

ariya.hi...@gmail.com commented:

Good point on proxy support!

Since stand-alone feature is one of the PhantomJS highlight, does providing command-line options, e.g. --proxy like in wget as well as reading environment variable give an acceptable solution?

 
Metadata Updates

• Status updated: Accepted

[alextreppass]

alextreppass@gmail.com commented:

Sure, a --proxy ip:port would be great. Some (SOCKS, for example) might also require username / password.

[curiousdannii]

curiousdannii@gmail.com commented:

As long as it accepts domains as well as IPs.

[ariya]

ariya.hi...@gmail.com commented:

 

 
Metadata Updates

• Label(s) added:
  • Component-Logic
  • Component-Example
• Milestone updated: Release1.1 (was: ---)

[ariya]

conversi...@gmail.com commented:

I have this working and will update my fork at https://github.com/clintberry/phantomjs. I added getops functionality and added proxy support. If you like it pull it on in to the master.

[ariya]

ariya.hi...@gmail.com commented:

Yes, patch is welcomed!

As long as the getops solution works across different platforms, that should be fine. Otherwise, for this simple functionality we might fall back to easier string check.

[ariya]

conversi...@gmail.com commented:

I used this for getops: http://xf.iksaif.net/dev/qcommandline.html

[ariya]

ariya.hi...@gmail.com commented:

Any update on this?

[clintberry]

cl...@elojasystems.com commented:

I couldn't get it to compile on windows. I am not sure if it is the getops or because I got the bleeding edge source code of phantom. I am going to try and compile it with version 1.0 and see if that helps.

[ariya]

ariya.hi...@gmail.com commented:

Might be related to my change to support GIF. It was not well tested on Windows yet.

[clintberry]

cl...@elojasystems.com commented:

I am still new to Git, so maybe I did this wrong, but I pushed my changes to the 1.0 branch on my fork. It compiled fine for me on mac and windows. If I need to do something different let me know.

[clintberry]

cl...@elojasystems.com commented:

Pushing to 1.0 seemed silly. I re-pushed my changes to master, but now I am afraid I don't have all of your changes in there. Give it a look and see if I did anything wrong.

[ariya]

ariya.hi...@gmail.com commented:

The change set is slighty too big. It will cause major compatibility problem as well since now the script must be passed using --file and the script arguments using --args.

I believe in this simple use case the use of QCommandLine does not really outweigh the extra code. I will try to rework your patch to use simple argument checking.

Thanks!

[clintberry]

cl...@elojasystems.com commented:

It actually will work just the same as before. It accepts the first argument without a switch as the file name, and then any arguments after that will be added to the args array just like before. The -i and -p switch are not required. Compile it and test it out, it should run just as you had it before.

If it is too big, I understand. I will be adding more options to it, so QCommandLine works great for what I plan for your amazing project.

[ariya]

ariya.hi...@gmail.com commented:

Ah I see now. I was wrong about the compatibility, I missed the QCommandLine::Mandatory part.

I still think you need to port the existing --load-images and --load-plugins command line option.

IMHO the design of QCommandLine is suboptimal/not suitable for this case. The use of signal and slot is not necessary. In all cases, this can be refactored out in the future.