Skip to content
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

Auto exporting does not work for POST requests #12

Open
xglin opened this issue Oct 31, 2014 · 5 comments
Open

Auto exporting does not work for POST requests #12

xglin opened this issue Oct 31, 2014 · 5 comments

Comments

@xglin
Copy link

xglin commented Oct 31, 2014

I have seen many discussions on the trick to make auto exporting for POST requests, but that does not work reliably or behave as same as GET requests.

For every GET requests, after pageloadtimeout (which defaults to 1500ms), the requests are automatically saved to har directory that I specified.

However, for POST request, it seems it won't be triggered to be saved by itself. If I set pageloadtimeout to be very big, as some people suggested, those POST requests will be combined with preceding GET request. Since we can't tell how long each request (GET and POST) will take, the pageloadtimeout has to be set very long in order to cover all POST requests in the test. However, the biggest problem is those POST requests are combined into one har with preceding GET request.

What I want to achieve is to capture har file for each individual click (for both GET and POST), so we can monitor client performance on per user click basis. I set extensions.firebug.net.defaultPersist to false, which nicely group the GET requests into separate har files per click. However, I can't make POST requests to be saved in its own har file without attach to preceding GET request.

I am using latest available firefox (v33.0), firebug (2.0.4), netexport (0.9b6).

@ktrzeciaknubisa
Copy link

+1 Auto exporting POST data would be also useful for swf files making their own connections.

@SebastianZ
Copy link
Member

+1 Auto exporting POST data would be also useful for swf files making their own connections.

Requests done by SWF files happen outside of Firefox - at least as long as you use the Flash plugin - and therefore cannot be tracked by Firebug/NetExport.

Sebastian

@ktrzeciaknubisa
Copy link

Requests done by SWF files happen outside of Firefox - at least as long as you use the Flash plugin - and therefore cannot be tracked by Firebug/NetExport.

Not going to argue with that. However I'm using Flash application for which FireBug 2.0.7 properly displays new POST requests/responses each time I press something (button, tab, etc.) inside swf object. Would be great if NetExport was able to auto-save them.

@ktrzeciaknubisa
Copy link

I modified this NetListener sample and I'm able to auto-save POST messages (without NetExport).

However, as @xglin wrote:

those POST requests will be combined with preceding GET request

I get the same behaviour. I wonder, how one can avoid that? Looks like file.postText inside NetListener.onResponseBody callback has already something added at the beginning of the string, like:

Referer: https://......
Content-type: application/x-amf
Content-length: 439
[POST DATA]

@SebastianZ
Copy link
Member

However I'm using Flash application for which FireBug 2.0.7 properly displays new POST requests/responses each time I press something (button, tab, etc.) inside swf object.

Do you use (Shumway](https://github.com/mozilla/shumway) instead of Adobe Flash? In any case you should post a test case here, so your issue can be reproduced.

However, as @xglin wrote:

those POST requests will be combined with preceding GET request

I get the same behaviour. I wonder, how one can avoid that? Looks like file.postText inside NetListener.onResponseBody callback has already something added at the beginning of the string

This is something @janodvarko should be able to answer.

Merry Christmas!

Sebastian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants