Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Catalyst-Plugin-ErrorCatcher CPAN distribution.

Report information
The Basics
Id: 72781
Status: resolved
Worked: 3.7 hours (220 min)
Priority: 0/
Queue: Catalyst-Plugin-ErrorCatcher

Owner: chisel [...]
Requestors: perl [...]

Bug Information
Severity: Wishlist
Broken in:
Fixed in: (no value)

Subject: FEATURE REQUEST: Show parameters and referer
Download (untitled) / with headers
text/plain 380b
Hi, it would be very nice when Catalyst-Plugin-ErrorCatcher could show the parameters that were sent with the request and where the request came from. Sometimes it's very hard to reproduce errors when you don't know anything of these. I may write this code in some time and open a pull request, but if you find the time to do it earlier it would be very great :-). Matthias
Download (untitled) / with headers
text/plain 1.3k
I'm having a blonde moment and can't work out why referer is more useful than URI (which already exists). Nonetheless I've pushed a change to github ( that adds: Referer, Params(GET) and Params(POST) to the report if the information exists. I haven't made these optional, so it's new information that gets 'forced' onto all users. My only concern is POST data potentially being quite large. I'm not yet sure how best to deal with this. Imagine the POST data is a JPG image, or a very large text blob ... what should I output? All of it? A substr() of it once it goes over a certain size? A 'TOO BIG' placeholder if it's too large? Right now the output (excluding the unchanged stacktrace section) looks like this: Show quoted text
---- cut here ---- Exception caught: Error: Undefined subroutine &TestApp::Controller::Foo::three called Time: Wed Nov 30 19:53:26 2011 Client: (localhost) URI: http://localhost/foo/referer?fruit=banana&animal=kangaroo Method: POST Referer: Params (GET): animal: kangaroo fruit: banana Params (POST): slayer: kendra vampire: joe random
---- cut here ---- I've added tests for GET, POST and mixed GET/POST requests. The output above is from a mixed request. Let me know your thoughts on large POST data.
Download (untitled) / with headers
text/plain 192b
The closing-paren got snarfed into the URL in my last comment. The correct URL is:
Download (untitled) / with headers
text/plain 419b
Wow, that was fast ;-). I'm going to test it right now! We have a web app with a bunch of Javascripts, which do many things on client side and return data to the server. The app dies if some parameters are not present so we get notified when something is wrong. Because an URI can get called from several pages with different Javascript snippets the referer can help us to track down the real bug in our JS files.
Download (untitled) / with headers
text/plain 331b
About large POST data... Can you differ between binary data (like a JPG) and large text blobs? If yes, I'd suggest to replace all binary data with a "BINARY DATA" placeholder + length in bytes. For large text blobs print a substr() as proposed + length in characters or bytes, whatever is best. What do you think about this?
Download (untitled) / with headers
text/plain 257b
On Thu Dec 01 11:00:32 2011, MDIETRICH wrote: Show quoted text
> What do you think about this?
Off the top of my head I'm not sure how to (easily) deduce the content type of some large random form data. I'll look into using something like File::Type and see how far I get.
Download (untitled) / with headers
text/plain 664b
On Thu Dec 01 11:53:20 2011, CHISEL wrote: Show quoted text
> I'll look into using something like File::Type and see how far I get.
How about something like this (from test diag()): # # Params (GET): # fruit: bananabananabananabananabananabananabana...[truncated] # # Params (POST): # image_gif: image/gif # image_png: image/x-png # long_text: kangarookangarookangarookangarookangaroo...[truncated] # pdf_file: application/pdf # I might tweak it to only file check if we reach a certain length - the module is quite naive in it's matching and could be easy to 'lose' parameter data if the value just happened to match the magic mime values looked for in the data.
Download (untitled) / with headers
text/plain 191b
I've uploaded RC1 of the next release here: Let me know if you have any problems, or if you're happy with the changes.
Download (untitled) / with headers
text/plain 193b
Am Fr 02. Dez 2011, 04:43:49, CHISEL schrieb: Show quoted text
> Let me know if you have any problems, or if you're happy with the changes.
Works fine for us, we're absolutely happy with this now :-). Thanks!
Download (untitled) / with headers
text/plain 266b
On Fri Dec 02 13:50:41 2011, MDIETRICH wrote: Show quoted text
> Works fine for us, we're absolutely happy with this now :-). Thanks!
I uploaded the new release last night: Thanks for the feature request!

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to