From: SourceForge.net <no...@so...> - 2012-12-17 12:50:44
|
Feature Requests item #3596294, was opened at 2012-12-15 08:55 Message generated for change (Comment added) made by elof You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=361118&aid=3596294&group_id=11118 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Win32 integration Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Martin Olsson (elof) Assigned to: Fabian Keil (fabiankeil) Summary: Show full clickable URL + method in MS-Win console Initial Comment: Concerning the MS console window... 1) Currently, debug level 1 show lines like this: 2012-12-15 16:50:41.422 00000d40 Request: www.foo.se/bar/spacer ...while debug level 1024 display: 2012-12-15 16:50:41.422 00000d40 Crunch: Blocked: http://www.foo.se/bar/spacer I would like both URLs to be displayed in a consistent way, i.e. add "http://" to the debug 1 message: 2012-12-15 16:50:41.422 00000d40 Request: http://www.foo.se/bar/spacer 2012-12-15 16:50:41.422 00000d40 Crunch: Blocked: http://www.foo.se/bar/spacer 2) Currently, debug level 1024 show blocked URLs in blue, while level 1 does not. I would like both URLs to be displayed in a consistent way, i.e. make URLs in debug 1 messages blue as well. 3) Now that all URLs are shown in a consistent way, please also make all blue URLs clickable. Any URL shown in the console should be clickable so one can easily follow them and debug individual requests without having to manually copy and paste the strings to a browser. 4) Debug level 1 and 1024 only show the word "Request" or "Blocked" but no information about the method used. Please add like this: 2012-12-15 16:50:41.422 00000d40 Request (GET): www.foo.se/bar/spacer 2012-12-15 16:50:41.422 00000d40 Request (POST): www.foo.se/bar/spacer 2012-12-15 16:50:41.422 00000d40 Crunch: Blocked (GET): http://www.foo.se/bar/spacer 2012-12-15 16:50:41.422 00000d40 Crunch: Blocked (POST): http://www.foo.se/bar/spacer 5) Debug level 1024 currently only log that an URL has been blocked but not the reason. Please add the reason, like this: 2012-12-15 16:50:55.111 00000d88 Crunch: Blocked (GET): http://www.example.com/nasty-ads/sponsor.gif {Nasty ads.} 6) The sixth sub-request is not as important as the five ones above, but if it is easy to do, please add the server response code to the level 1 messages like this: 2012-12-15 16:51:42.144 00000e50 Request (GET:200): www.bar.se/baz 2012-12-15 16:51:42.144 00000e50 Request (POST:404): www.bar.se/gazonk (There's no need to add a response code to the level 1024 message since the request haven't actually been sent to any server, so no true response code actually exist) PS. I would much rather have the above items fixed than switching to using debug level 512 (common log format), since the latter won't show me the blocking reason, etc. ---------------------------------------------------------------------- Comment By: Martin Olsson (elof) Date: 2012-12-17 04:50 Message: 1) I just want it to look consistent i all logs. 4) This is a duplicate only if I enable 512 as well, and since I don't want to do that, it would be very useful to have this info in the level 1 log messages. If I remove level 1 and 1024 and enable 512 instead, I will see the method (and the response code), but I will no longer see what is being crunched in a highlighted fashion (and possibly not the blocking reason either). That's the reason I don't use 512 today. 5) Neat. When will it be released? 6) Yes, that delay could mess things up. Ignore this bullet. 7) I want to EITHER use 1 + 1024 OR level 512. If I enable all three the log will be quite messy and have duplicates all over, and since some messages are delayed they are displayed out-of-order. The config even states that debug level 512 should be used by itself. I request bullet 4 since I don't want to enable level 512 as well just to get it. The alternative would be to use level 512 only, but my feature request #3596295 was closed and rejected, giving me no visibility of the crunches. ...so I still stress the need for item 4. ---------------------------------------------------------------------- Comment By: Fabian Keil (fabiankeil) Date: 2012-12-16 10:00 Message: Thanks for the suggestions. 1) That seems reasonable to me but note that the protocol is only used for http:// requests. 2) I believe that would be a side-effect of #1. If not, it's unlikely to happen without patches due to being Windows-specific. 3) Windows-specific and I don't have a strong opinion on this. 4) This would duplicate information that is already shown with other debug levels so I don't consider it useful. 5) Privoxy 3.0.20 already has a new debug directive to show the applying actions which includes the block reason. 6) This again would duplicate information. It also would require delaying the message until the response arrived. I don't see why you would have to switch debug levels when you can simply enable all the ones that provide information you care about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=361118&aid=3596294&group_id=11118 |