-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #228: Allowed the setting of custom headers #229
Conversation
* Separate headers with a comma (e.g. "Accept-Language:it-IT,Max-Forwards:6"). | ||
* See <a href="https://github.com/ariya/phantomjs/wiki/API-Reference-WebPage#wiki-webpage-customHeaders">PhantomJS docs/a>. | ||
*/ | ||
public static final String PHANTOMJS_CUSTOMHEADERS_PREFIX = "phantomjs.customHeaders"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the actual string is wrong here.
Also, I'd call it PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX
.
Could you please add a bit more explaination to the PR? BTW, thank you very much for this effort. |
@detro I've updated the pull-request with an example usage and (basic) explanation. Also note that I changed: PHANTOMJS_CUSTOMHEADERS_PREFIX = "phantomjs.customHeaders" to: PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX = "phantomjs.page.customHeaders" (per your suggestion). |
I'm stupid. This doesn't match the way "phantomjs.page.settings.x" works: that requires you to set 1 Capability PER setting. setCapability("phantomjs.page.settings.userAgent", "My user agent");
setCapability("phantomjs.page.settings.AllowXSS", true); and so forth. That's why I called it I'd like to maintain consistency: could you please refactor? Btw, the changes you have done are all going in the right direction. |
I'd argue that it'd be more consistent implementing it in a similar way to PhantomJS. If in Phantom we're doing page.customHeaders = { 'Accept-Language': 'it-IT' }; Shouldn't GhostDriver be doing: capabilities.setCapability("phantomjs.page.customHeaders", "Accept-Language:it-IT"); Of course if you still don't want to do that, I'm happy to change it (although I don't think it makes much sense). |
Leaving the way you suggest will make 2 capabilities, that do 2 very (very!) similar things, require a totally different approach. And I can't change It's a tool, and people don't like when you break their tools :) |
Point taken. I personally preferred sticking as closely as possible to the PhantomJS implementation, but it does make it a little messy (comma delimited argument passing, eurgh). So before I go ahead and make the changes, you want something like: PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX = "phantomjs.page.customHeaders.";
capabilities.setCapability(PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX + "Accept-Language", "it-IT"); Right? :) Edit: Facepalm, corrected to PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX, was tired! |
PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX = "phantomjs.page.customHeaders."; //< notice the dot at the end
capabilities.setCapability(PHANTOMJS_PAGE_CUSTOMHEADERS_PREFIX + "Accept-Language", "it-IT"); |
Issue #228: Allowed the setting of custom headers + minor documentation Issue #228: Corrected the Java customHeaders prefix Allowed setting of page custom headers via capabilities, similar to page settings
Done and done. Updated the pull-request description to reflect the changes. I agree that it's nicer as you suggested. Cool! |
Issue #228: Allowed the setting of custom headers
Merged. |
This pull-request allows you to pass custom request headers down to PhantomJS. The syntax for doing so is a little different to the PhantomJS equivalent, but is relatively simple:
In PhantomJS, you might do something like:
And (with this patch), you can do:
Similar resolved issues: Issue #134
Technical notes:
After the iterations on the implementation, we've ended up with a bit of duplication. My Javascript skills are sufficiently bad that I'm not going to refactor it without the tools to test afterward (latest commit is from a dying laptop with no charger), so I'll leave that in for now. To be fair, it reads fine anyway.
Also, it'd be nice to update the page.customHeaders object so that we don't lose any previous key/values that may have existed. Not really a problem, as it doesn't look like we have any default headers at the moment anyway, but it might need to be changed in the future.