Adding support for getting body of requests or responses #10158

Closed
ghost opened this Issue Jul 4, 2011 · 89 comments
@ghost

saleh...@gmail.com commented:

Adding support for accessing body of requests (useful for http post requests) in the onResourceRequested call back.

Which version of PhantomJS are you using? 1.2

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

@ariya
Owner

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

I'm not sure how we would encode the content. Typed array comes to mind, but that's not widely supported yet.

@ariya
Owner

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

 

 

Metadata Updates

  • Title updated: Adding support for getting body of requests or responses
@ariya
Owner

jgorn...@gmail.com commented:

It seems the body would be part of the "text" property in the content object of the HAR response object: http://www.softwareishard.com/blog/har-12-spec/#content

@ariya
Owner

jgorn...@gmail.com commented:

After doing some more research, wouldn't it be feasible to add the content of the response to a text property in the data emitted when listening to the NetworkAccessManager::handleFinished and performing a readAll() on the reply argument? Then taking that byte array and converting to a QTString?

Currently, the signal is coming from: http://doc.qt.nokia.com/4.6/qnetworkaccessmanager.html#finished
Then the reply object is: http://doc.qt.nokia.com/4.6/qnetworkreply.html#finished
Where we could call readAll to : http://doc.qt.nokia.com/4.6/qiodevice.html#readAll

Just wanted to check if I am on the right path here.

@ariya
Owner

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

I'm not sure readAll is wise there. Doing that definitely leaves WebKit with data at all?

@ariya
Owner

jgorn...@gmail.com commented:

Are you saying that if you call readAll on the response object, it won't leave that data available for WebKit to read?

@ariya
Owner

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

Yes, I am quite sure calling readAll will eat all the received data and leave nothing.

@ariya
Owner

jgorn...@gmail.com commented:

Off the top of your head, would there then be a way to read a copy of response data? If you can point me in the right direction, I can start experimenting with it.

@ariya
Owner

jgorn...@gmail.com commented:

I did a little more research and found out that it might be possible to write a proxy for the QNAM and the NetworkReply. This way you could capture the data received and still have it accessible after the read has finished. An example I found pointed me to: http://gitorious.org/qtwebkit/performance/blobs/master/host-tools/mirror/main.cpp

Am I on the right track here?

Thanks!

@ariya
Owner

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

Yes, proxying both the network access manager and network reply is the right approach.

@ariya
Owner

jgorn...@gmail.com commented:

I'm on my way to figuring this out but have run into a snag. Keep in mind I'm not that familiar with C++ but after adding in the reply proxy, I get a compile error of:

Undefined symbols:
"vtable for NetworkReplyProxy", referenced from:
NetworkReplyProxy::NetworkReplyProxy(QObject, QNetworkReply)in networkaccessmanager.o

Here is my latest gist of the NetworkAccessManager:
https://gist.github.com/1131280

Any help would be greatly appreciated!

@ariya
Owner

jgorn...@gmail.com commented:

Pull request: #124

We'll definitely need to go through a code review on this one :)

@ariya
Owner

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

See 578aa6c.

We need an option to enable and disable (by default) this data gathering (since it introduces some performance penalty).

 

Metadata Updates

  • Milestone updated: Release1.3 (was: ---)
  • Status updated: Accepted
@ariya
Owner

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

Hmm, some ownership issue and/or race condition in the proxy might provoke a crash.

@ariya
Owner

jgorn...@gmail.com commented:

Ariya, I'm sorry, but I'm not following. Can you elaborate a little more?

Also, when I get some time, I can add in a patch to disable the use of the proxy.

@ariya
Owner

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

I fixed the potential crash in 37404ba.

@ariya
Owner

jgorn...@gmail.com commented:

Awesome!

@ariya
Owner

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

Closing this one as it is implemented already.

For the API/settings improvement, head to issue 236.

 

Metadata Updates

  • Status updated: Fixed
@ariya
Owner

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

Reopened. Likely needs to be rescheduled soon.

It causes regression, see issue 238.

 

Metadata Updates

  • Status updated: Accepted
@ariya
Owner

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

 

@ariya
Owner

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

I can't find a quick way to resolve this. Probably I will revert it for the time being.

@ariya
Owner

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

Unfortunately I have to revert this, see eb25581

We need to have a better working solution for 1.4.

 

Metadata Updates

  • Milestone updated: Release1.4 (was: Release1.3)
@ariya
Owner

jgorn...@gmail.com commented:

Ariya, do you have any other information on what needs to be added to the proxy so we can get this back in? I'd like to be able to help and get this resolved.

@ariya
Owner

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

I have not investigated further. Basically the fix should not regress netlog and netsniff examples (easy to test). See also issue 238.

@ariya
Owner

jgorn...@gmail.com commented:

Sounds good. I will try to look into this and see if I can find a solution. I will also look into adding the flag to disable the proxy for performance reasons.

@ariya
Owner

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

Not enough time to resolve for 1.4. Postpone to 1.5.

 

Metadata Updates

  • Milestone updated: Release1.5 (was: Release1.4)
@ariya
Owner

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

No activity, reschedule.

 

Metadata Updates

  • Milestone updated: FutureRelease (was: Release1.5)
@ariya
Owner

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

Issue 422 has been merged into this issue.

@ariya
Owner

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

Issue 501 has been merged into this issue.

@ariya
Owner

webmas...@webmaster.ms commented:

I think, the embedded phantomjs server can act as a proxy which intersects and saves the content of the dowloading files and the sending POST.
The only problem is its unability to parse queries like "GET http://www.google.com/ HTTP/1.1".
The server responses with "Error 400: Bad Request, Cannot parse HTTP request: [GET]".
It seems that fixing the server would be an easier and faster solution for the people wanting to access the bodies of requests and responses.

@ariya
Owner

jgorn...@gmail.com commented:

I do have a commit that adds the ability to read the responses @ https://github.com/jgornick/phantomjs/commits/reply-proxy-issue-158. However there are 2 other issues I know of that need to be fixed in order to get this accepted:

  1. Issue #238 - REGRESSION: netsniff.js does not produce HAR dump
  2. Issue #236 - Settings to control network capture

I'm pretty slammed right now so if someone else is interested in helping out, I'd appreciate it :)

@Paxa

Pavel.evst@gmail.com commented:

I made simple solution for that, #246
In my fork page.onResourceRequested accept hash with postData if its POST-request

Why you need proxy for that? I think its quite simple

@ariya
Owner

webmas...@webmaster.ms commented:

jgornik, there is one more issue with NetworkProxy approach:
synchronious XMLHttpRequest doesnt work (but asynchronious still)

testcase: https://gist.github.com/2664974

@JamesMGreene
Collaborator

james.m....@gmail.com commented:

I would want the resource response text to be not just readable but writable as well (so I can modify a particular resource's response body for instrumentation purposes). See http://code.google.com/p/phantomjs/issues/detail?id=539 for more info.

@bshamric

bsham...@gmail.com commented:

For what it's worth, I have a workaround that I've been using. I followed phantomjs's code into the QTNetworking core and found where the cache is being saved and how the names are hashed. I replicated that using phantomjs and then pulled the content from the QT's cache file. I only tested this with images since that's all I need it for, there will definitely be cases where text documents don't work with it, but for what it's worth, here is my code: https://gist.github.com/bshamric/4717583

@JamesMGreene
Collaborator

james.m....@gmail.com commented:

Interesting idea, thanks for sharing. Unfortunately this approach also breaks down when the responding server indicates (via HTTP response headers) that the requested resources cannot be cached.

@standpat

I'm just interested: will this be in 1.9?
I mean, when I see the outgoing requests, some of them may be interesting. Since this content is already being downloaded, ability to print/save body of (e.g. GET) responses would be great. From what I underastand, this is currently not possible

@ariya
Owner

The patch in #246 needs to be significantly updated.

@lukebennett

Obviously 1.9 is out now and doesn't include a fix for this. Any idea if it will make 2.0? (or 1.10 depending on what the roadmap is). I'm desperate to be able to access response bodies. I've tried a number of unsuccessful workarounds and am currently trying to decide whether it's worth persevering further or to just sit tight and wait.

@Paxa Paxa added a commit to Paxa/phantomjs that referenced this issue Mar 27, 2013
@Paxa Paxa #10158 show postData in onResourceRequested callback (updated to curr…
…ent master)
197b7cb
@Paxa Paxa added a commit to Paxa/phantomjs that referenced this issue Mar 27, 2013
@Paxa Paxa #10158 show postData in onResourceRequested callback (updated to curr…
…ent master)
4187a13
@dwightgunning

I have a question about how to access the Response body. Raising it here as #10422 which deals with this specifically was closed with the note merging it with this issue.

However I can't see any reference to the response body in PR #11181 which seems to be the trigger for closing this issue. Perhaps I am missing something?

If the response body is available to onResourceReceived in the 1.10 branch then I'm gonna try build from source :-)

@JamesMGreene
Collaborator

@dwightgunning:
Issue #10422 was a duplicate feature request of this issue (#10158), so it was merged in and closed as you noted.

This issue (#10158) is still open exactly because, as you said, we have not yet implemented accessing the body of a response object in onResourceReceived yet. Currently, the 1.10 branch only includes the code for accessing the request body (via PR #11181).

@JamesMGreene
Collaborator

@Paxa: Any chance you want to take a crack at implementing the PR to access response bodies as well?

@ariya
Owner

@dwightgunning Your comment caused a confusion in my part. After re-reading it again, now I understand the situation better. I also wish GitHub could distinguish between referenced commit in this official repo vs somewhere else (@JamesMGreene can you escalate this to GitHub folks?).

AFAICS this issue (#10158) is not closed yet. The only commit in the official repo is commit fcdd274. As the commit message indicates, it's only about POST data in the callback, not body response in general.

@dwightgunning

Sorry my bad... I saw the red "closed" box against the PR and mistakenly thought it was indicating this issue was closed.

Two rookie questions about this project in one day... sorry guys.

I'll shut up and wait patiently for the response bodies (wish I could contribute a PR but wayyy to little time / skills for this one). Awesome work with the project BTW!

@JamesMGreene
Collaborator

@ariya:
The repo that is referencing the issue is noted in the "title bar" of the respective reference comment:
  image

Is that what you are referring to? If yes, please clarify if you would like to see it further differentiated. If no, then can you clarify what you mean?

There is, however, a separate problem that I've noticed where if I push a commit to a fork and reference an issue from the upstream repo that I have push permissions to, it will actually close that issue. For example, a push to "JamesMGreene/phantomjs" with the commit text "Fixes #10158" would actually close this issue in "ariya/phantomjs" even before being merged.

@JamesMGreene
Collaborator

@dwightgunning: No worries, thanks for your interest and kudos. :)

@ariya
Owner

@JamesMGreene I can see the repo name but I think anything outside the official repo should be hidden by default ("Show All Reference" button could be handy), especially if that external commit is in the PR which has been closed. Otherwise, the issue will be easily flooded with potentially outdated changes (which may cause some confusion).

@JamesMGreene
Collaborator

P.S. I've passed the "fork commit closing upstream issue" problem along to my GitHub contacts.

@JamesMGreene
Collaborator

@ariya: I agree in that I also find those references very distracting sometimes, though sometimes important (e.g. when an issue of ours is a blocking issue to another product).

@ashkulz

Compilation on MSVC windows fails due to fcdd274 -- according to this question on StackOverflow you need to undefine max.

http://stackoverflow.com/questions/1904635/warning-c4003-and-errors-c2589-and-c2059-on-x-stdnumeric-limitsintmax

@Vitallium Vitallium added a commit that referenced this issue Apr 14, 2013
@Vitallium Vitallium Fix compilation with MSVC 2010
Issue #10158: #10158
This bug introduced by the marco max( ) defined in <windef.h>.
It replaces max( ) with another statement but still preceeded by numberic_limits<Type>::
The workaround is to use the parenthesis
3edcabe
@Paxa

@Paxa: Any chance you want to take a crack at implementing the PR to access response bodies as well?

@JamesMGreene In what cases you would need it?

I start doing it, if content is plain text - it works well, but if content is image then it shows something like this
"body":"GIF89a¡"
If convert to base64 - it works well, is it convenient to work with base64? Any ideas about it?

I think with my previous commit, when phantomjs uploads file it will not work correct too.

@Paxa

You can see how I did it here Paxa@4ab5627

@standpat

Any chances of including this into 1.9.1?

@JamesMGreene
Collaborator

@standpat: Typically patch builds will only include bug fixes, not new features. @ariya is the one to make the final decisions on that, though.

@Vitallium Vitallium added a commit that referenced this issue May 14, 2013
@Vitallium Vitallium Limit the maximum request post size to 10 MB (megabytes).
std::numeric_limits<qint64>::max is too big for QByteArray (throws Out of Memory exception).
Set up the limit like it was done in Google Chrome
Ref: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/inspector/NetworkResourcesData.cpp

Related to issue #10158 #10158
f8e79fb
@ariya
Owner

@standpat Of course not, this is a new feature and can't be included in a maintenance release.

@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 28, 2013
@Paxa Paxa Show postData in onResourceRequested callback. 6d65f25
@alisman

Is there any update on this much needed feature? Thanks to all.

@ariya
Owner

@alisman Let's minimize "are we there yet?" inquiry.

From the FAQ (http://phantomjs.org/faq.html):

Q: Is there any update on issue XYZ??

Any progress related to an issue, whether it is a change in the plan or an implementation check-in, will be always posted to the issue page. This is part of PhantomJS contribution guide, it is essential to the development workflow. If an issue hasn't received any new update for a while, a question like "Is there any update?" has an obvious answer.

@alisman

I am eternally grateful to you all for voluntarily building this tool, so I don't want to annoy anyone, but I wouldn't say the answer is obvious. The comment history suggests a lot of activity, near-release, and then dormancy. If the issue has indeed been dropped, or a solution isn't imminent, then we would try to implement ourselves, but there's no way for us to know other than asking.

@ariya
Owner

Sure, asking is encouraged, just be more specific. Also, often times the mailing-list is quite useful for "meta" discussion.

@detro
Collaborator

Is anyone working on this specific feature? The thread is so long, I fail to follow if there is a Pending PR or it's still in the making.

I can see few patches by @Paxa on this issue, but I seem to understand they haven't been merged to master yet. Possibly because a PR hasn't actually been raised (or is just not linked here?!!?!?).

@Vitallium
Collaborator

I think no one is working on it. We recently pushed the code for getting the body of POST requests.
[1] fcdd274

@JamesMGreene
Collaborator

No one is working on it.

@maxcan
@ariya
Owner

IIRC some patch was landed, but it causes regressions and thus gets reverted:

@ariya
Owner

It's also helpful to read the original issue on Google Code: https://code.google.com/p/phantomjs/issues/detail?id=158.

See also eb25581.

@detro
Collaborator

Thanks for the update guys.
I guess this could be done but it needs some commitment.

I have originally reached this issue because, during a Meetup, Aaron Lisman asked about this specific feature and that work on it had "stalled".

But in a recent email he mentioned there might be some time investment from one of his company devs.

I guess the saga of this issue continues... :)

@olegus8 olegus8 added a commit to olegus8/phantomjs that referenced this issue Mar 13, 2014
@olegus8 olegus8 Adding support for getting body of requests or responses cd4b780
@macbre macbre referenced this issue in macbre/phantomas Mar 22, 2014
Open

SPOF checker #25

@dparshin dparshin added a commit to dparshin/phantomjs that referenced this issue Apr 25, 2014
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

ariya#10158
9fbeef4
@kisel kisel pushed a commit to kisel/phantomjs that referenced this issue May 22, 2014
@dparshin dparshin resource body is not converted to base64 anymore cd7d6b2
@kisel kisel pushed a commit to kisel/phantomjs that referenced this issue May 22, 2014
@dparshin dparshin fixed multiple onResourceReceived events for one real event 7b0e2ab
@kisel kisel pushed a commit to kisel/phantomjs that referenced this issue May 22, 2014
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

ariya#10158
aac74b5
@akosicki akosicki pushed a commit to akosicki/phantomjs that referenced this issue May 26, 2014
Aleksander Kosicki added response body to response object in onResourceReceived event
ariya#10158

Conflicts:
	src/networkaccessmanager.cpp
343f46e
@nerevar

Hello.
Is anybody going to fix this issue?
What about #11181 ? Seems it contains needed functionality (read access of http request body)
We need this in our project

@vic-cw

@bshamric thanks a lot for the tip on checking the cache. Did you find a way to decompress the files after you get their contents ?

@zackw
Collaborator

Retagging -- it sounds like there's several patches floating around and it's a "simple matter" of getting them unified and tested and committed?

@zackw zackw removed this from the FutureRelease milestone Apr 19, 2015
@Paxa

Common dude, it's been almost 4 years, people need this feature. And it's 3 years since my first pull request, and I refreshed 2 years ago.

If you really don't like my code (and any other pull requests if there are any), just sit and code it by yourself. It took for me just couple hours without any experience with C++ before. Or you want to wait another couple years? :)

I always wonder why people like to reject pull requests instead of fix it and merge it if code not perfect.

@zackw
Collaborator

@Paxa I'm just digging through old bugs and figuring out which still need something done, I haven't looked at your code at all. We will get to it eventually.

@diorray

Hey @ariya any updates about this issue?

@madelson

👍

@Paxa

👍

@dparshin dparshin added a commit to dparshin/phantomjs that referenced this issue May 18, 2015
@dparshin dparshin Added proper 'copyright' headers to the new files cf179e4
@Vitallium Vitallium added a commit that referenced this issue May 21, 2015
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

#10158
1375519
@Vitallium Vitallium added a commit that referenced this issue May 21, 2015
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

#10158
37d22d5
@shlomis

+1

@Vitallium Vitallium added a commit that referenced this issue May 31, 2015
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

#10158
d0fde08
@Vitallium Vitallium added a commit that referenced this issue May 31, 2015
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

#10158
327f91d
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin resource body is not converted to base64 anymore 0180f3a
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin fixed multiple onResourceReceived events for one real event 86633f2
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

ariya#10158
d923bdd
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

ariya#10158
30fd1f2
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin Added proper 'copyright' headers to the new files c4b1321
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin resource body is not converted to base64 anymore d66e367
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin fixed multiple onResourceReceived events for one real event 077cfcb
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

ariya#10158
b19c72c
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

ariya#10158
c21546f
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue May 31, 2015
@dparshin dparshin Added proper 'copyright' headers to the new files d05bdc6
@Vitallium Vitallium added a commit that referenced this issue Jun 27, 2015
@dparshin dparshin Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

#10158
daf3b0e
@Vitallium Vitallium added a commit that referenced this issue Jun 27, 2015
@dparshin dparshin response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

#10158
7d25c76
@eperez84

Anxiously awaiting the addition of this feature!

@Vitallium
Collaborator

Landed in 434d4e0

@Vitallium Vitallium closed this Jun 30, 2015
@Vitallium Vitallium removed the In progress label Jun 30, 2015
@Noiwex

Response (#1, stage "start"): {"body":"","bodySize":169...
Response (#1, stage "end"): {"body":"","bodySize":0
what the hell

@alexdrk

@Noiwex I had the same problem, if you change "shouldCaptureResponse(req.url().toString())" to just "true" ( https://github.com/ariya/phantomjs/blob/54a54dc0687a4b93562285d4f632dcafe2c7bf4f/src/networkaccessmanager.cpp#L388 ) without the double quotes it should return every response. Apparently this is just a quick (and probably wrong) hack to get the responses. There must be some way to set the pattern for the urls to match in javascript, but I haven't figured it out.

@zackw zackw added a commit to zackw/phantomjs that referenced this issue Aug 6, 2015
@zackw zackw Restore logic for `--local-url-access=no` accidentally deleted by #10158 82096f4
@xsyntrex xsyntrex pushed a commit to xsyntrex/phantomjs that referenced this issue Sep 1, 2015
Derek Dupree Merge branch 'master' of https://github.com/ariya/phantomjs
# By Zack Weinberg (4) and James M. Greene (1)
# Via Zack Weinberg
* 'master' of https://github.com/ariya/phantomjs:
  Fix compilation with GCC 5. (Issue #13518)
  Fix an issue with loading JS modules contains a last-line comment
  Additional test cases, using iframes, for issue #12752.
  Restore logic for `--local-url-access=no` accidentally deleted by #10158 (#13412)
  Ignore more things created by the newer Qt(Webkit)
5e77a71
@rockswang

Are there any documentation about this feature?

@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium Added proper 'copyright' headers to the new files
ariya#10158 (reverted from commit c4df640)
0cc4cf4
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium response body is only available in onResourceReceived event,
if url matches one of the patterns in 'page.captureContent' property

ariya#10158 (reverted from commit 327f91d)
ccb7ce1
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium Fixed body string initialization code (0 byte for empty strings)
Also fixed same code in filesystem module

ariya#10158 (reverted from commit d0fde08)
edb4cb2
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium setting bodySize attribute of resource object on 'end' stage
ariya#10158 (reverted from commit 977b280)
9269cdb
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium fixed multiple onResourceReceived events for one real event
ariya#10158 (reverted from commit 616d991)
072a444
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium resource body is not converted to base64 anymore
ariya#10158 (reverted from commit 87625a2)
70e9e80
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium added response body to response object in onResourceReceived event
ariya#10158 (reverted from commit 434d4e0)
7d65feb
@Vitallium Vitallium added a commit to Vitallium/phantomjs that referenced this issue Jan 19, 2016
@Vitallium Vitallium added response body to response object in onResourceReceived event
ariya#10158 (reverted from commit 434d4e0)
4b00536
@arrowing

How long I can use reponse body in released version?

I will use proxy for it. :(

@Noiwex

#10158 (comment)

or make changes in cpp and compile

@Noiwex
@MichalBu

This fix was removed from 2.1.1 - why?
How can I get the build with this feature?

@Vitallium
Collaborator

@MichalBu You can find more information here #13922

@jbruggeman
jbruggeman commented Aug 3, 2016 edited

I was able to hack together some code together to re-add this functionality. Basically I edited QNetworkReply to overload read/readAll, intercept the data, and dump it to a QByteArray. I then exposed and Base64 encoded it.

It's not nice (one might even call it terrible), but it works.
https://github.com/jbruggeman/phantomjs
https://github.com/jbruggeman/qtbase

@jksecurity
jksecurity commented Aug 30, 2016 edited

@jbruggeman As I really would like this feature, could you explain how to set this up using the sources you provided? I am not sure how I would get the build to pick up the recompiled qtbase for example (preferably without overwriting the system wide qtbase).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment